My organisation is using JIRA as a sort of service desk, meaning we need to allow our clients to raise tickets directly in JIRA. Unfortunately, because the sprint field appears in all create issue screens, any ticket that the client raises, they can add them directly to Sprints. We don't want this and have already removed their ability to edit tickets as a result.
What we are looking for is a way that we can still allow the client to raise tickets but not add them to the sprint, If necessary can this be done by letting external clients see a different create issue screen to the one that internal users see?
(Edited) I omitted some steps. Let me be more explicit.
In the following steps, substitute <YOURS> with the subdomain of your instance, and <KEY> with the project key of the project you are going to configure:
From now on, users that only have been granted with access to the project through the "Customers" project role shouldn't be able to schedule issues to a sprint.
Can you confirm it works?
Sorry to jump into the discussion here, but I am not expecting this to work. The Manage Sprints permission allows you to control these actions:
It does not influence the ability to add issues to a sprint. See Atlassian documentation on this for more background.
You are right about the Manage Sprints capability.
However, note that Schedule Sprints is supposed to be required to add an issue to a sprint.
Please, look for "Add issue to sprint" here:
I will edit my answer to remove the Manage Sprints permission stuff, thanks.
Indeed. The Schedule Issues permission @Ignacio Pulgar is referring to, relates to the Due Date field, not the sprint. The first and most logical option - in my opinion - would be to use JIRA Service Desk as a service desk. It is designed specifically for that purpose. In there, you design the screens for your customer the way you want and show only what you want your customer to see, decoupling the internal JIRA UI from the customer portal (the screens available to your customer).
Maybe you have been looking into that already, maybe not. As long as you are not in that direction yet, a workaround might be to remove the Sprint field from the create issue screen altogether. And keep it on the Edit and view screens only. The effect will be that you're internal people will no longer be able to add an issue to a sprint on creation, but that might be a tradeoff you might need to make to accomplish what you're describing for now.
I think this is an interesting discussion :smile:. Note that the Schedule Issues permission is a Board permission. So it relates essentially to being able to drag issues into a sprint in the backlog of your scrum board.
In Niall's question, we are at issue creation. So there is no board in play yet. Given the permission would effectively influence the ability to add issues to the sprint, it would result in a permission error on creation of the issue. I don't think it does, but even if it would, I don't think that would be desired behaviour. So I guess making sure the Sprint field is not on the Create Issue screen is the cleaner (and simpler) solution.
Although using JIRA Service Desk as your Service Desk would definitely be the cleanest :smile:
Walter Nice & interesting discussion :smile:
Look at the creation screen of a user with just Browse Projects and Create Issues permission:
Observe that the Sprint field shows a None, despite of the fact that there are already existing sprints.
Now, look at the Create Issue screen of the same user, once it has been granted with Schedule Issues permission too:
Note that, on granting the Schedule Issues permission as the only action taken, the Sprint field becomes enabled.
So, it is not just a board permission, but a permission required to set or edit the Sprint field.
End of discussion :cheeky:
If you want to keep chatting about Service Desk pros and cons, or any other thing, we might be going too off-topic, but you might contact me by google hangouts or email: ignacio.pulgar at incentro dot com
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event