Matt Doar_tzgiej Community Champion

How would the integrity checker have caught the problem in the case of using different custom field types? But yes, workflows can have all kinds of old, deleted info still embedded in them. Which is tricky to remember to check for. Exporting a workflow as XML and grepping for the custom field id sometimes helps me remember…

Yes, this is confusing. I wish the workflow editor did not allow changing status names in this way. I guess I use the text editor more than the graphical editor, so I haven't been bitten recently by this. Anythng that leads to near-duplicate object names in Jira is an accident waiting to happen!

1,007 is ... horrendous. Did someone have to configure them manually? Mind boggling. I find there is a balance to be struck between minimizing the number of transitions, and making a workflow maintainable. I know I've done Clever Things in the past with scripted conditions to make transitions with the same name but…

This one is trickier for me. I like the idea of one, true final status such as Done. But I know that sometimes people want to set a system Resolution value such as Won't Do in the transition to a final status and call the status "Cancelled" or some such. I guess a JQL query on status is not empty and resolution = "Won't…

This isn't just for Jira. Or even all the Atlassian products. This is for all services/tools that you manage. Without somewhere to play with the thing, how will you ever make the mistakes that are needed to learn?

Oh yes, workflows. I generally state baldly that any more than 9 statuses in a workflow is a smell. It's not always true but it does make me suspicious. Generally a workflow needs * A "new, no work done yet" status * A "approved and ready for work to start" status * A "work in progress" status * A "work has been done,…

And they need to be able to have holidays!

I'd look into email to page gateways I think. Not so fast but the delay might be within a few minutes. 

Good reminder about this change, thank you. I wish the docs about it had examples of what could go wrong if you have issues with many comments etc. And a clear process to identify whether a Jira instance is at risk if the default settings are used.

It may also be worth reaching out to the support team at Adaptavist, the ScriptRunner vendor

The most common problem is that the field configuration scheme for the Jira project is not applying the expected field configuration to your test issue. Double check that the issue type and field configuration are as expected. Then test with a simple piece of Wiki markup before testing with links. Good luck!

The existing data will probably no longer be visible. But this is a question for the vendor of the XRay feature really

1. Postgres is the most tested database with Jira. But use the DB that you have the most local experience with and local assistance 2. Using a remote database is generally better for large Jira instances. For small instances it likely doesn't matter

If your plan uses Agile boards, you can add holidays to the agile boards to do this. But not directly in plans

I suspect that utf8-mb4 is needed, not just utf8. https://confluence.atlassian.com/adminjiraserver0901/connecting-jira-applications-to-mysql-5-7-1155490939.html

Also: key in (ABC-123, DEF-234, EFG-111) will work

9.12 hasn't been released yet. Due before the end of 2023 I think?

"This would not be using the Jira global rank feature" the first thing I would do is ask "why not?". What are the advantages of being able to see a number to represent an ordering? If you still wanted to go ahead with this, you could have an external service that extracted the current value and status of each issue in the…

That's really useful to have all this documented, thank you! However I'm not sure that filter names are unique except per user. Should work if you add the userid though.

A locked field cannot have its configuration changed. A read-only field cannot have its contents changed

Another way to debug this is to take the filter clause1 and clause2 and clause3 and add the issue key you want to find and issuekey=TEST-123 Then remove each clause one at a time until the query returns the expected issue. The last clause you removed was the problematic one.

Stale cookie? Try a different browser on the original computer perhaps

Oh, there it is To stop project admins from using automation rules, go to Automation Rules, click on the ... button, Global Configuration, uncheck the box

https://confluence.atlassian.com/automation/manage-permissions-for-project-admins-1141480595.html looks easier but may be older doc from before it was shipped with Jira 9

https://confluence.atlassian.com/automation/setting-configuration-properties-1026539532.html has info about how to restrict who can use automation I think. Or there is probably a system app at Manage Apps that can be disabled to make the whole of automation go away

[ and ] are not allowed either. Colons are a valid character but will cause the labels not to appear in the autocomplete text. JQL searches for labels with colons seems to work though. Equals (=) seems to work There is also a limit of 255 characters for a label

Too many to count. Mostly because my mouth sometimes speaks before my brain. One from a long time ago when my wife was still in seminary, training to be a priest. We were at a formal dinner all sitting at a large round table. I was way across the table from the bishop who was the senior person at the table. As we all got…

For some context, we have about 9M issues and 1600 of those have a resolution date but no resolution. And 600 have a resolution but no resolution date. I'm not planning to fix this in our Jira unless I see evidence that it affects our users.

In normal operation, the code that sets a Resolution also sets a Resolution date. And clearing the Resolution clears the Resolution date. But there is history here. For the first few years the Resolution Date was part of the Jira Toolkit plugin and not everyone used that. So some of your older data might be from when there…

Using an app will likely be lest cost and effort in the long run.