JIRA Agile seems to allow project administrators with JIRA Agile boards and a Simplified Workflow to create new statuses. Does anyone know how I can only allow JIRA admins to create issue statuses?
Alternatively, how can I prevent Simplified Workflows from being used in enterprise-scale JIRA instances in a simple way?
I guess in the end I have to do something to stop the conditions listed at https://confluence.atlassian.com/display/AGILE/Using+JIRA+Agile+Simplified+Workflow#UsingJIRAAgileSimplifiedWorkflow-Whycan'tIswitchtoSimplifiedWorkflow? from being valid. This is currently:
You will only be able to switch to Simplified Workflow if:
However that seems to say that only JIRA admins can use simplified workflow, which is not what I think I've seen. I may be mistaken though
I know this is really old but I'd like to add some input.
We use the announcement banner to hide certain elements from JIRA users...then it's not that hard to use a script (javascript/AJS) to check if the current user is member of a certain group...if so then update the css display of the elements, like addStatus. This can be done in the announcement banner, and limits certain options like add column or status via the board config.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hammer approach:
If you've got nginx or apache (urk) in front of JIRA, you could maybe identify the rest end point that GH calls when it creates statuses and just return back some static son. JIRA Agile will say that things are broken... Then just tell the JIRA Admins to create the statuses properly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
ow!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Matt,
Change the workflow on the project - just create one that has the same states, etc, as the simplified but create it by hand, not as a copy. Then JIRA shouldn't allow project admins to switch their project's workflow to the simplified and since it isn't simplified they won't be able to add statuses.
There are some 'dark' flags set on the simplified workflow - much like how JIRA Agile custom fields are 'locked' - that JIRA Agile checks before allowing statuses to be added (we found this out when our Transition Reorder Addon would fail when handling the simplified workflows). I don't know more specifics unfortunately but can ask a developer for more details on the Fix he did.
-wc
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Project admins shouldn't be able to switch the project workflows to simplified. You need to be an admin to do it (or at least you used to).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That would work true. But I have hundreds of workflows, projects, thousands of boards etc so I'd really like a way to only allow JIRA admins to create statuses.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
yea, that's a different kinda problem - sry, should have realized the twist here... I've had a couple of other thoughts, let me noodle them about a bit and I'll post what shakes out. The first (evil) thought I had was implementing a listener that would first disable/delete status objects created by non-jira-admins and then create an issue humbly requesting forgiveness from the JIRA Admin group (via new issue created in project X) for overstepping their authority, etc etc...something embarrassing, anyway, as that sort of manipulation tends to displace all but the most determined. I don't know if you can detect when one is created, though, so it'd get complicated if you couldn't squish it instantly. Anyway, interesting question, so thanks! cheers -wc
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Looking at the source code - it's interacting directly with the status service (through a couple of layers of abstraction). The only way to block it would be at the rest level. Now you could intercept the javascript call that the button and just override it.
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.