Sync error because issues are archived, what's the best practices and recommendations?

General Questions
1

Created by Exalate Support.

I have Jira Data Center version 9.12.7 and Exalate plugin version 5.16.0-java8-j8

One issue with key A-1 is archived (the project is NOT archived), but have a remote link with B-2 that belongs to the project TANDEM that is archived.

The issue B-2 was updated with a new Jira link with another issue, and that event changed the values of a Scripted Field (plugin ScriptRunner) that counts the total amount of linked issues. So, in summary, the issue B-2 tried to sync with A-1, but both issues are archived (one of them directly, and the other belongs to a project archived). Currently we have a pair of Exalate errors, that says the user of Exalate can’t update the issues.

What are your recomendations to resolve this errors, and prevents to occur again in the future? I look for solutions that prevent this type of errors with archived issues with any automations that are currently programmed or be programmed in the future. Maybe an update of the sync script? If we avoid the update of archived issues in one automation, a future mistake in another automation shoots this type of errors again, and I look for a response that prevents absolutely this errors among all automations (current or future).

3

There are quite a few ways of going about this in my opinion:

  1. Unexalate the issues after they are archived. Do it manually or programatically based on your workflow. The unexalate will not update either issue, but will break the exalate-link between the two.
  2. Elevate the permissions of the proxy user so that you do not get this error again, but this would mean that exalate is updating archived issues (not ideal in my book).
  3. In the scripts, just check if Exalate is trying to update in an archived project
  4. and if that is the case, just return. The pseudo code in the incoming script would be:
if (issue is archived)
     return

Hope it helps.

Thanks
Majid

5

@Majid Thanks for your response. I´m the original author of this issue, but Martin post in my name here.

  1. We can´t unexalate the issues, because the delete of the remote link updates the system field “Links”. After using the Clean-Up Tools, the sync is stuck in “cleaning” status untile the issues were restored. Only after restore each issue, the sync ends in that issue. So, is not possible to unexalate after archive.
  2. I don’t know if the Jira Data Center permission schemes allows to update archived issue. I think that is not possible either.
  3. I tried to detect archived issues and return in Incoming ant Outgoing scripts, but the sync fails with an error BEFORE the sync script is executed. I think Exalate check if the issues are archived, and fails before executing the scripts.

So, I try to confirm if is a bad idea to support sync between archived issues. In my opinion, it IS bad idea (after the previous test). In order to fix the sync error I needed to restore both issues, delete the remote link between them, and archive again the issues. One of them belongs to an archived project, so I needed to restore/archive the entire project.

6

Indeed, it is not a good idea to work with archived issues, but the catch on number 3 is very interesting. So if I understood correctly, you are testing whether the issue is archived and you are doing this in the Incoming script, but it errors out even before that. If that is the case, indeed, this would be a no-go.

The only other suggestion I have is the unexalate post-function, if you can adjust your workflow to handle this.

Thanks
Majid