Making Changes at Scale

[Clark Everson]

At my company we have been experience issues as we are trying to make changes at scale as we begin to standardize Jira.

When making changes, such as workflows with different statuses or updates to custom fields with stale data, the update date  changes. Sometimes the update isn't even captured in the history.

However, what we really are looking for is a way to make it so the update date isn't changed at all.

Some of the projects have old historical data so when these dates get changed it impacts reporting negatively.

Any ideas are appreciated!

[Rodolfo Romero - Adaptavist]

Hi Clark,

How are you making the changes to these issues? Did you create new schemes and assigned them to the project or are you making changes on the fly to the existing issues and schemes. The best approach would be to make new schemes and when they are finalized, change the project to start using the new scheme and your "update" dates should remain intact.

Rodolfo

[Clark Everson]

Everything was made net new. Every scheme type has net new names that were being adopted. There are also other changes such as SSO etc being done as the company is shifting tooling

[Rodolfo Romero - Adaptavist]

And how are you executing the update of issues? Bulk data change or configuration scheme change?

[Clark Everson]

Hi @Rodolfo Romero - Adaptavist 

It's not possible to do bulk changes to new schemes without changing the scheme itself first.

So both. You can turn off notifications via bulk changes. However even changing schemes causes the update date to change, though it doesn't log itself in the Activity or History Logs.

[Rodolfo Romero - Adaptavist]

Hi @Clark Everson

I probably didn't explain myself well. Let me try a different way...

Changing the status of all the tickets in a project can be done in 2 ways. 1) Modify the status using a bulk change, which will modify the "update" date, or 2) by creating a copy of the current workflow, assigning it to the workflow scheme and publishing it. These changes are not supposed to change the "update" field. You can also update the workflow itself, if that is sufficient and when it's published, the changes should not impact the "update" field either.

Let me know if you're doing #2 and you still see the "update" field updated.

[Clark Everson]

@Rodolfo Romero - Adaptavist 

We're doing 2 but not just for workflows, for all scheme types. Users are selecting them themselves using delegated project admin. However as there is no activity log or history log for what is actually causing the update data to change we don't know what scheme changes are affecting it.

In addition there are other system changes happening from switches to more secure SSO to configurations etc, but again we don't know what is actually causing the update date to change.

When people use bulk change, this is being captured in the history and activity log, so it's easy to identify. 

The changes we are referring to are ones that aren't being captured so we don't know why that date is changed we just know it's changed because the logs show the last update as several years ago either history or activity.

Hope this makes sense.

Clark

[Pramodh M]

Hi @Clark Everson 

Optimizing an instance with all the schemes, fields, and other data you have in the instance is a step-by-step procedure. It matters the most when these schemes or fields are already being used.

Editing options of existing schemes are not a recommended way to optimize the Instance. We have to look at how data is being affected in the process.

I suggest you look at the requirement first, if there is a need to extend the feature of current existing schemes you could use the existing configuration to build and have it for users. Otherwise, create a new configuration.

You could also look at marketplace plugins that assist with these requirements where we can actually limit the creation of workflows, fields, etc.

let me know your thoughts on this!

Thanks,
Pramodh

[Clark Everson]

Hi @Pramodh M 

In regards of our optimization and schemes they are all actually net new and we are using a tool called Delegated Project Admin to allow users to make changes.

All of these things you mention plug in wise we have and they are what we are using. We have also limited admins and are preventing changes and we are still hitting snags.

The issue is when they make changes to a new workflow, because the statuses are being changed name wise as part of the standardization its being recognized as an update event but nothing is logged in activity.

we've been working on requirements and the process for almost two years now and planning but as we start executing there's been numerous issues, and this is one of them.

Looking at Atlassian's bug log: https://jira.atlassian.com/browse/JRASERVER-29817

This is not only an issue we have faced but so have others. What we are looking for is if anyone has come up with solutions to this. Statuses is just one example.

Another example was when we rolled out SSO and usernames changed due to sso, it caused the assignees or reporters usernames to change, and it was recognized as an update even though it was system wide. This broke reporting for a lot of different projects. We are looking at ways to prevent or turn this off if possible during these system update windows.

Feel free to ask additional questions