Hi if anyone stumbles on this conversation, I'm using a validator on the "Create Issue" Transition.
'Users in a field are/aren't in a project role'. Choose Field Reporter and select the roles you need.
Of course, this means you have a different workflow per issue type
Atlassian don't have the resources to support every single plugin their users *might* want to install. OnDemand is set up to be supportable, so they have to limit the range of plugins to ones they know they can support.
I completely understand their exclusion of the script runner though. It's a good, flexible, well supported plugin, which would usually be a good canididate to include in OnDemand. However, it's power is that it exposes most of the internals of Jira to the administrators and effectively allows them to code. Which, in the hands of an inexperienced developer/admin, is a recipe for generating vast numbers of support calls which all start "I tried to do clever thing X with the script runner and it went bang". So, despite being useful and well behaved, it can be a nightmare to support.
@Nic, Yes I completely agree with the fact that you can do loads of cool internal things with script runner without the need of trying to write you own plugin, however i kind of disagree with "despite being useful and well behaved, it can be a nightmare to support", since the plugin is so damn useful thus it should be supported on the onDemand instance, yes there would be bulk of support tickets but with time naive admins/users would know the right way to handle it's power. Large number of support tickets shouldn't be a deterrent in supporting this useful plugin in the onDemand Environment.
Large numbers of support tickets generated by allowing people to make (potentially catastrophic) mistakes simply is not supportable.
I've worked with the script runner a lot. In most cases, it's great. But when you get a combination of the script-runner (or other clever plugins) and an inexperienced admin, you end up wasting a LOT of time working out and unpicking the mistakes. And in some cases, weeks carefully rebuilding messed up systems.
The vast majority of OnDemand users would be fine with this, but the handful that aren't would chew up a vast amount of support time. It's simply not worth it!
For me your stmt. "The vast majority of OnDemand users would be fine with this, but the handful that aren't would chew up a vast amount of support time" actually makes the plugin worth-while to be supported on the onDemand instance. Also, you have preview clause in some scripts and should also test it on the test environment first.
No, it's completely the opposite.
Think of it this way, you go to a meeting with your boss and say "I'd like to allow our users to inflict massive damage on their system, with us having to pick up the pieces when they do? For free". No-one in their right mind would take that gamble.
Well kind of agreee with you but not completely, there are only handful users that would do any hard to the system and even out of those handful users there would be very few users who would end up doing something catastrophic, I think it's a "calculated risk" keeping in mind the value provided to the majority of users who would be using the plugin.
You would also know the fact that there are some paid plugin being used whose functionality can be replicated by the script runner plugin which is free of cost thus it offers some monetary benefit as well for the end user with some basic scripting skills.
That's the point - the "handful of users that would do any harm" are going to make mistakes that chew up a disproportionate amount of support time. The calculated risk here is "massive big red expensive thing".
You really need to consider this from a support manager's point of view instead of the user. Try it - you'll find any sane support manager will laugh at you and then hold out their paw for you to triple their budget before they'll do it.
Your statement makes sense ONLY if Jira was free. When you charge for a platform, then support volume is part of the game. You just can't mark tickets that are important to an organizations "Won't Fix" and then disable their ability to improvise because support is overwhelmed by inexperience users. Remember you are in business to support your customers. You either have to provide the features they want/need (regulated by Atlassian/Jira developers) or allow them to experiment themselves. If you choose neither, then ( u know the REST !!!)
Amine - I'm using JIRA 6.4.3. and I don't see the options you are describing. Adding a validator to the Create Issue transition in my workflow, only provides the option of select 'Permission Validator' then choose a global permission option. I don't see where to select which project roles I want this rule to pertain to. Did something change or am I looking in the wrong place?
As Nick says, workarounds are available by using a Velocity processesed message custom field for view, and put the condition in the default value in the custom field by which the create button will be disabled.
Link to the old question forums http://forums.atlassian.com/thread.jspa?messageID=257250857
I know there's a lot of interface changes in 5, but I've not really worked with v5 seriously yet.
The "edit message" field though - that comes from the Jira Toolkit plugin (which is one of a handful of plugins that are so useful, I struggle to use Jira without them)
@Renjith : Hello, I've the same point and would like to visit the link in the old forum you've given, but I'm unable to find it : http://forums.atlassian.com/thread.jspa?messageID=257250857
Where could I find it in the new forum ?
Thanks in advance for your help
The forums were shut down, I'm not sure Renjith has re-posted the same answer anywhere.
Also, this is quite old and it relies on the "velocity processed message" fields from the Jira toolkit, which aren't there any more.
The principle is similar though - you can use a "message field" to tell the user that they cannot create this issue type and a mandatory field that isn't on screen to force validation to fail.
The workarounds discussed in that forum (if I remember correctly) are there in this feature request - https://jira.atlassian.com/browse/JRA-5865.
But I am afraid that it is so old that those scripts won't work anymore for the new JIRA interfaces (also considering that we have now pop-up dialogs for Creating issues).
@Niccan you just let me know where i can find "message field" and "mandatory field ", and if we put this mandatory field that is not on screen to force validation to fail , you mean by that , certain users won't abe able to see the option of create an issue for example or they will get a message and create will fail?
Message fields are in the Jira Toolit plugin. Make sure that's enabled in your Atlassian account and then the next time you add a custom field, you should see "message field" on the list of types.
Mandatory fields are set in "field configurations". They will not actually help you here though - you've reminded me that you want "certain users", which is not possible without some coding. A field is either mandatory or optional, the user trying to create the issue is not important.
Maybe not so nice, but there is a way
1. Make unique Workflow for each Type
2. In each workflow set in validator on Creation transition a specific Permission (like Set Issue Security, Delete All Comments, Edit All Comments, Delete All Attachments or Time Tracking Permissions which we are not using)
3. Create permission schema where assign this specific Permission to proper Group of users
at the end Group has right to create issues of specific Type
Two vulnerabilities have been published for Confluence Server and Data Center recently: March 20, 2019 CVE-2019-3395 / CVE-2019-3396 April 17, 2019 CVE-2019-3398 The goal of this article is...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs