Users do not see their related Assets in a Request Offering
We have the situation, that some users do not see their assets (where they are the custodian) inside a Request offering - As they need to select their client in order to request software, this makes it unusable for them.
The criteria inside the prompt is the following:
We also have an SQL query inside a custom dashboard, where every user sees his/her assets:
SELECT [HardwareAssetID] AS Inventory, [HardwareAssetHasCatalogItem_DisplayName] AS Model, [HardwareAssetType] AS Type, [HardwareAssetStatus] AS Status, [SerialNumber] AS Serial, [AssetPurpose] AS Purpose, [ControlDate] AS Date FROM [ServiceManagement].[cachert].[csnCached_HardwareAsset] WHERE ConfigItemOwnedByUser_BaseManagedEntityId = @UserID
When these users open this dashboard, the asset is shown. I had a look at the Servicemanager and Servicemanagement DB and for all of these users only one user is there - so it is not a problem with the username.
Since version 11.6 we also have the problem, that the "cpex_SmRelationship" table is no longer updated, until we reset the platform cache inside the Dynamic Data Troubleshooting page. After that it gets synced once at the next cycle, but afterwards no syncs happen again. Might this be related to the issue with the Hardware Assets not being shown inside the RO?
Best Answer
-
Simon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭
The rel. table bug is addressed in a PR and the issue with the owned by seems to be an SCSM issue
0
Answers
I want to add that for these users the owned by Relationship and their assets are present in the cpex_SMRelationship Table and I also created a test RO where I can select the user and his/her assets are shown - this works as well. So it seems like an issue with the "Token: Portal User Name"
We also tried it on other clients, just to be sure it is no certificate or Browser cache issue -Still no difference.
I now try the session.user in the debug console, maybe I find something there...
The rel. table bug is addressed in a PR and the issue with the owned by seems to be an SCSM issue