The amount of overhead the workaround solution for this issues adds is actually ridiculous. We are building an automated import solution so we need to use the REST Api, setting or updating each user value like that is just unreasonably painstaking. It feels like a fix here is overdue

Hi all, I wanted to provide a quick update re the suggested workaround.

Whilst we have not been able to prioritise adding the feature of supporting User type attributes on External/Discovery Import yet, our teams were able to solve the issue that objects with a set 'User' attribute type could not be updated via imports.

I.e. the below workaround now no longer requires clearing the 'User' attribute values before each subsequent import:

Workaround

1. Perform the Discovery/ext import
2. Update the Jira account Attribute Values in Assets for all those objects using a different method.

Thanks Italo, I've voted and commented on the new bug issue as I think this is a critical issue for a system that is meant to be an "Asset management system" this bug means that all our asset imports are currently failing.... so for us it makes Jira assets useless until this bug is resolved

49ca96ef3477 - Atlassian created a bug for the external import related to our issue.

https://jira.atlassian.com/browse/JSDCLOUD-12410

+1

Also, I just faced the exact same issue related to 49ca96ef3477  

The real critical piece is that once you have an object which contains an attribute type of "User" and this is set to a value, you can no longer update the object attributes through an external import. That object will just fail to update and the import history will record an error of "User not found in Jira". Remove the "User" attribute value stored for that object, and you may now update all of the other attributes as needed without issue. Obviously, this is not a feasible workaround. 

The object has an attribute of type User and the import fails to update any object that has this attribute set;

Just adding my vote here as this bug as advised by Atlassian support seems to be responsible for us now getting import errors constantly, I add here the correspondence I received from Atlassian support:

Yes I have been able to see the errors on the import history for the import configuration and I've been doing some investigations on these errors.

Looking into the 'unauthenticated' errors shown on the error logs, it looks like the Add support to User type attributes on External Import bug was responsible for these errors. The process Insight goes through when an Attribute is updated is to verify all Attributes when any are updated.

So, even if an unrelated Attribute is being updated via External System Import, if the Jira account Attribute (In this case, the 'Owner' attribute) has a value, it will return an error and not process the updates since that value cannot be verified – looking into the objects that were referred to by the error messages, they all have the 'Owner' attribute filled in

REDACTED LINKS

I'm afraid the best workaround that can be provided until this bug is fixed would be the following:

1. Set Jira account Attribute (Owner) Values to empty/null via a different method for the objects that need updates.
2. Perform the Discovery import again

That is certainly an option, though in my particular case we are running this through a Lambda which has time constraints on run time and the more API calls you have to make to check thousands of user objects the closer you get to this limit (as well as Atlassian's own throttling limit). 

After thinking more about it this morning I have actually solved the problem (in at least my case) by adding one more layer of indirection.

Instead of having a user object with an attribute that points at a Jira account, I created a new "Atlassian Account" object which contains an attribute pointing at the Jira account. Now I can freely update the first user object on an ongoing basis with all of the attributes that are actually changing (display name, account status, job title, etc). The user object has a unique id field which is set for its corresponding Jira Account object and is how they are finally matched up. The Atlassian account for a particular user should in theory never change except in rare circumstances, so not being able to update this is workable, and if needed we can use the REST API as you mentioned.

We had device objects that contained an "assigned to" attribute Device which points at a user object. To reference this Jira Account, we now need to go one more layer deep.

Pulling the devices for a particular reporter used to look like this:

     Laptop."Assigned To" -> User."Jira Account"

But now looks like this:

     Laptop."Assigned To" -> User."Jira Account" -> "Atlassian Account".Id

To pull a list of devices assigned to the current reporter of an issue with an AQL filter in a JSM custom field: 

objectType IN ("End User Device") AND "Assigned To"."Jira Account"."Id" = currentReporter()

Note: Our device schema has a parent object type called "End User Device" and then object types like "Laptop", "Desktop", "Tablet" etc that inherit from this.

@Dan Witkowski It is possible to update all of those objects via the REST API, even if there is a User object in your schema, because the API doesn't do the same (any?) validation that the external import tool does.

I'll admit that it's a huge pain to have to do all of this, but I have a "creator" script that runs and external import and then an "updater" script that manages any changes to those objects. 

This feature is critical to anyone that wants to implement their own integration. I can workaround setting the Atlassian Account Id through an external import, since I have been able to do this through the REST API. 

The real critical piece is that once you have an object which contains an attribute type of "User" and this is set to a value, you can no longer update the object attributes through an external import. That object will just fail to update and the import history will record an error of "User not found in Jira". Remove the "User" attribute value stored for that object, and you may now update all of the other attributes as needed without issue. Obviously, this is not a feasible workaround. 

In summary, to make any real use of this product it is necessary somewhere in your schema to link to a "User" (Atlassian Account) so you can start doing interesting things in JSM. However, once you do so, you can no longer use any automated means of keeping the other attributes up to date with data from your directory or MDM systems. This means you are stuck manually adding or updating objects which you have no way of reasonably keeping up with or ensuring any level of accuracy.

Adding another vote to this issue. This is a piece of critical functionality we need to manage approval workflows, work distribution, and escalations.