When we started out with our Jira Service Management implementation we started registering our users of IT services as assets within the same object schema as the IT assets. However the scope of our implementation has grown and now we would also like to register other (non-IT) items and relate them to our user assets. These non-IT items are registered in a different object schema.
We can achieve the linking by enabling "Allow others to select objects from this schema" on our IT-schema. However this also gives users of the non-IT schema insight in the IT assets. To mitigate this I would like to migrate the user assettype to a separate HR-schema. Using the "object schema import"-function I can copy all the user assets into a seperate schema. However this does not create relations between the user assets and their (IT) assets and already created tickets.
Is there a way to recreate these relations with the new user assets in the HR-schema without having to manually recreate all of them?
Hi Gert,
even if I am not fully aware about the exact links you use, but this has been described more or less in this documentation: How to import Assets object types with attributes referencing existing objects | Jira | Atlassian Documentation
Find the quick steps here:
1. Recreate the object type with all attributes in your HR object scheme
2. Export all the user objects as CSV including all the attributes they have. See this discussion for details: Solved: How to export assets data (atlassian.com)
This of course does not include the connected issues (this can only be handled by some kind of automation)
3. In the HR scheme, create a CSV import and import your file created from step 2. This should allow you to also create the mappings to other assets. See the first link for further details on mapping.
4. The objects should now be created identical to the existing ones and only the links to the connected tickets are missing. Those connected tickets are calculated by the issues that use the object in a Assets custom field.
Automation of some kind is needed here, so the steps will vary on what you use. Therefore the steps can only be described high level:
5. To migrate those old values, create a new custom field and let it point to your new user object type (you will delete it afterwards).
6. Now, iterate over all issues that have a value in the original custom field and grab the label of the object. Set the label as value to your new custom field. Depending on the solution you use, you might have to lookup the object key for the label first in the new object scheme and use the object key instead.
7. verify your new field has been filled correctly. If so, you may either rename the old field to some backup name and rename the new one to the original name. Or you keep the new field as is and simply change the screens accordingly.
Let me know, if this helped!
If you need some more advice, you might let us know, what kind of automation you are using, so we could give you more guidance on steps 5-7.
Regards,
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.