Hi all, have like 30k+ tickets to update a single asset custom field on. To be safe I tested on one ticket and set up as follows:
| Project Name | Project Key | Project Type | Issue Key | Summary | CField_Assset |
| Proj | PRO | software | PRO-222 | Test Summary | d3923r0-324e-32r2r:1111 |
uploaded it and no errors, says 1 work item updated successfully.
BUT the ticket is gone? I go to PRO-222 and it says "You may have no access or it does not exist", no search for summary, key etc can make me find it? Console says 404.
Anyone been through something like this before?
Cheers!
Hold the 30k run until you know where PRO-222 went.
Atlassian has a KB for this exact operation, updating an Assets object custom field by external import, and the recipe in it is much narrower than what you sent. Verbatim: "You'll need at least three columns: Work Item Key, Summary, and Custom Field. During this setup, the Summary column can be left empty." You sent six, three of them Project Name, Project Key and Project Type. The word Project does not appear anywhere in that KB.
The Summary column is the one I would look at first. That same page says to leave it empty on purpose: "An empty Summary column will prevent unnecessary or unwanted updates to the Issues' Summary." Yours carried the literal text Test Summary, so the import very likely rewrote the summary on that work item. If it did, searching for the summary you remember will return nothing while the item is sitting there perfectly intact under a title you did not choose.
Before you conclude it was destroyed, note that "You may have no access or it does not exist" is one message covering two different situations, and the 404 does not separate them either. Query it as an admin over the API, GET /rest/api/3/issue/PRO-222. A 200 there means it exists and you have an access or a location problem. A 404 as admin means it genuinely is not at that key any more, and then the project's audit log will tell you whether it moved.
Either way the diagnosis costs one API call. Cheap, before 30,000 work items go down the same path.
Thanks for this will do a check via API soon. And try another ticket with a blank Summary to confirm it keeps the old.
If it helps I am doing this in a sandbox environment, so it isn't the worse that its gone. It was more I'm not sure where it went.
I will try it blank and see what happens this way. But I can confirm on the csv file (since I only did one) the summary it should overwrite with is correct.
Regarding the Project, Project Key etc. Thats where the 20K+ comes in (not that I tried 20K but the reason why I bring it up), the CSV importer in cloud is telling me I require it, if I'm importing fields across projects. It will not let me continue without them unless I specifically choose the project.
Fingers crossed on the api get. Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for this, did it again with summary as empty and it looks like it worked. Tried the API call on PRO-222 and its unfortunately showing 404, other IDs work however.
So will definitely be keeping that summary part blank! Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Good, and your correction on the Project columns stands. The KB I quoted describes the single-project case, where you pick the target in the wizard and the columns are redundant. Importing across projects is a different shape and the importer asks for what it asks for.
PRO-222 itself is still unexplained, though. A 404 on the API while neighbouring keys resolve tells you it's genuinely gone from that key, and the run that lost it carried a populated Summary and the Project columns together. Your successful run changed one of those. That leaves the other still untested at scale.
So before the real batch, take ten rows in the sandbox with the Project columns present and Summary blank, import them, then re-query the keys you touched. If they all resolve, the summary was the whole story and you can run with confidence. If any of them go the way PRO-222 did, you have found it on ten rows instead of thirty thousand.
Cheap either way, and it converts an unexplained disappearance into something you've measured.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Gabriela - LeanZero , gave it some time, and it looks like its appeared back today! Maybe it was an indexing issue of some sort? But even the API returns "200 OK" odd but will definitely do a 10 row check just incase. Cheers!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Calvin
What were the troubleshooting steps that you took to resolve it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've tried the following:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Nikola Perisic checked today and its back! I think maybe it was an indexing issue of some sort.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.