Config tool says the change is clean, something breaks anyway. how common is it?

Endri Vavla

Following up on my question yesterday about custom fields.

A couple of people pointed me at tools that analyse config before you deploy or delete something. Before I go and buy one I'd like to know how much to trust the green light.

Has anyone had one come back clean and then had something break anyway? And did you ever work out whether it hadn't checked that thing at all, or had checked it and got it wrong?

Mostly trying to work out how much of the checking I'd still need to do myself.

Matthew Sinclair

Presuming your speaking of custom fields based on your inference.

The problem with custom fields is the permission system is intrinsically designed to deny access by default. Even to Jira-Admin/Org-Admin level access.

You may be able to get into a space-settings page - but you won't get automatic access to JQL issues/tickets at-will.

This is made worse by the travesty of "Archiving" (sorry Atlassian its true - archiving is a joke).

Archiving hides entire spaces - but its not a true archive by any means what so ever - its still consuming resources and occupying slots in various ares in terms of schemes and fields.

Wish we could "Silo" the info out in some sort of data dump - but alas. (No not the backup/restore function :P and rather not pay money for a marketplace app as great as they are - which may end up doing anyway)

The thing we relied on when it came to custom field clean up is the following indicators beyond the tool:

How many screens is it living on?

How many spaces is it attached too?

How many contexts are present (which can help hint at spaces its attached too that may not be obvious)?You can turn these columns on when you search for fields in work items section of your Jira-Admin control panel.

Def. want the Custom Field ID# - very handy for speedy lookups.

Then check workflows and other things.

Dashboards/Filters we tended to ignore - we'd advised users to either use the correct field ID# (because we had serious duplication problems) - or just update your filter. With 5000 Jira spaces and counting - don't have time to chase them down.

By the time you get into the space you can attempt to attack it from there via the optimizer tool in a space context - problem is - marketplace apps tend to pollute the waters with their own fields.

Thankfully those tend to be locked fields anyway.

Worst case - you can do a scream test.

You get 60 days to reverse a decision once you "Trash" a field - provided you didn't empty the trash (if that's still a thing?)

When you recover a field - it puts it back where it was at the time you deleted it unless you pulled it off screens already.

Whatever you remove - document your notes/findings just in case you need to retrace yoursteps.

There are marketpalce apps that help you reverse course more cleanly however - Revyz I think its called - a backup tool is one of them.

Sometimes good old elbow grease is how you get there - you can also use Rovo to speed things up - however there's two problems with that

• Your consuming credits in doing that
• Rovo only see's what you see - and that means permissions block your path.

Frankly I wish Atlassian gave a general error to indicate "Data is present but you don't have permission" instead of something akin to "void" or whatever it is that isn't useful at all.

A permission flag for Org Admins or something that let us at least know something is there - just don't have access.

A locked door is fine - we just like to know something is stored in there is all im saying.

Sorry for my little custom field rant. 😁

The optimizer tool has come a long ways - but its got its limits too - they will continue to update it so it can only get better.