How to allows user to raise tickets but not be able to add them to a Sprint

[Niall Allen]

Hello,

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?

Thanks

Niall 

[Walter Buggenhout]

Hi Niall,

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.

[Walter Buggenhout]

Hey @Ignacio Pulgar, no offense and just trying to help. I see that it's there, but maybe that's an error in the docs. Here is more info on Scheduling issues specifically (also from the docs). 

[Ignacio Pulgar]

Hi Walter. No worries 

I agree the page you have provided should state that the Schedule Issues permission is also needed for adding issues to a sprint.

[Walter Buggenhout]

I think this is an interesting discussion . 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 

[Ignacio Pulgar]

Walter Nice & interesting discussion 

Look at the creation screen of a user with just Browse Projects and Create Issues permission:

no-schedule-issues.jpg

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:

with-schedule-issues.jpg

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 

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

Regards

[Walter Buggenhout]

Cool 

[Ignacio Pulgar]

1. Create and use a specific project role for those customers.
2. Grant them with at least Browse Projects and Create Issues permission.
3. Ensure they are not being granted Schedule Issues permission, which is needed for adding issues to sprints. (Edit issues permission is also needed, but they will need to have both to be able to assign issues to sprints).

[Niall Allen]

This doesn't seem to work. Following your above steps I am still able to add a ticket to the Sprint at the same time I create the ticket. 

[Ignacio Pulgar]

(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:

1. go to https://<YOURS>.atlassian.net/secure/project/ViewProjectRoles.jspa
2. add a project role with name "Customers" and click on the button "Add project role"
3. go to the permission scheme set on the project you would like customers to not be able to schedule issues to sprints:
    https://<YOURS>.atlassian.net/plugins/servlet/project-config/<KEY>/permissions
4. click on the button Actions > Edit Permissions, on the top-right corner
5. click on the button 'Grant permission' on the top-right corner
6. select the permissions you would like your customers to have, but ensure you do not grant them with Schedule Issues permission.
   A sample set of permissions that you might want to set is:
     Browse Projects
     Create Issues
     Transition Issues
     Close Issues
     Resolve Issues
     Edit Issues
     Add Comments
     Edit Own Comments
     Assignable User
     Assign Issues
     Create Attachments
     Delete Own Attachments
7. grant the permissions to the new "Customers" project role, and click on Grant
8. go to: https://<YOURS>.atlassian.net/plugins/servlet/project-config/<KEY>/roles
9. remove all customer user accounts from all other roles
10. if there are groups set under a project role, ensure no customers belong to them, or remove the group from the project role, if it is only has customers as members
11. now, add your customers to the project role "Customers"

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?

[Walter Buggenhout]

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:

• Creating sprints
• Starting sprints
• Completing sprints
• Reopening sprints
• Reordering future sprints
• Deleting future sprints
• Editing sprint information (sprint name and dates)
• Moving the sprint footer

It does not influence the ability to add issues to a sprint. See Atlassian documentation on this for more background.

[Ignacio Pulgar]

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:

https://confluence.atlassian.com/jirasoftwarecloud/permissions-overview-764478244.html

I will edit my answer to remove the Manage Sprints permission stuff, thanks.