Jump to content

Assets have lost their 'Used By' details, but they do still show in the 'properties' when you open the details


Paul Alexander
 Share

Recommended Posts

A load of our assets have lost the 'used by' information in the list view.

So, for instance, if I look at asset ID 35560, there is no 'used by' data in the field:

image.png.b335b46fa42661f4fcf46665201363f5.png

 

 

 

If I OPEN the details for that asset I can see that there IS a user associated with it:

image.thumb.png.bba9b5b2e5ba6c1f834eb70fa5d134f4.png

 

If I DELETE that user, and re-add him, then it does show in the list:

 

image.png.e1d1f2c1b345781c06242ce5250f5869.png

 

We've got thousands of these assets, and I really don't want to have to do this to all of them! Any ideas please? I did see that there was an update last night which mentioned this but it seems to have worked backwards for us..,...we didn't have this problem before the update! :)

Any ideas please?

 

 

Link to comment
Share on other sites

@Paul Alexander it *looks* to be related to something we were involved in. We logged this issue:

If we had a case mismatch when uploading the Used By data to link an uploaded Asset to an existing user (e.g. used UserName@Domain.Com instead of username@domain.com) then we found the Used by DID appear in the field for the Asset but did NOT appear in the Used by for the search filter. The system was recognising it in one place but not the other. I haven't yet looked for the effect on our data but at first glance we're not immediately missing Used by now.

It was categorised as a defect KE00174352 - [Service Manager] Asset "Used By" value is not displayed in the asset list when there is a case mismatch in imported asset user data.

It might be worth checking the underlying data to see if you have a case mismatch. I am not sure which way they fixed it but if it's not the same in both places for you then something is a little fishy still...

Link to comment
Share on other sites

Hi @Berto2002

Thanks for that....WE reported it a couple of years ago  and it was to do with the Database Asset Import Utility doing exactly what you've described above e.g. struggling to match up users if the uppercase/lowercase didn't match on the import csv.

I'll get it reported again - but hopefully if Hornbill fixes OUR instance, then it won't break yours again  :)

 

)

  • Like 1
Link to comment
Share on other sites

I can see that you've raised this as an Incident, so I'll let the investigation complete there.

For anyone else who may see this, the issue isn't that the Used By information is lost, it's that it was never there.
This will be caused by an Import incorrectly populating the Used By fields, but there being enough information for the Asset View to work out a most likely User.
Basically the fact that you can see anything under Used By in the Asset View is the defect, not the other way around.

Link to comment
Share on other sites

@Paul Alexander so there are a few things here that, perhaps, could use some clarification.

The asset data you have in your instance is incorrect as the database value for Used By is missing the user type part. This is due to import data which did not have this value at the time of the import. This needs to be rectified by adding this value in the import data.

While the values stored in Used By filed did not cause a problem in the UI, now there are additional checks in place that validate the format and in case of an incorrect one will not display the information. In other words, this was an oversight in the system (which was now corrected) but unfortunately this affected the values you currently have which are no longer displayed. The solution here is, again, to correct the values for the respective fields.

We have identified a defect whereby different letter cases in the user name will not be correctly parsed by the system leading to no values displayed in the Used By fields. This will be corrected shortly.

There is also the aspect of the import mechanism allowing incorrect URN (the format we use in these fields) to be stored in the database. We are discussing this with our development team so additional checks are implemented for the import mechanism to avoid this scenario going forward (prevent incorrect values to be stored in the DB).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...