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

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 

2 answers

0 votes
  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).

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. 

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

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.

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.

0 votes

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.

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). 

Hi Walter. No worries wink

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

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:

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

Regards

Cool thumbs-up

Suggest an answer

Log in or Sign up to answer
Community showcase
Published 8 hours ago in Confluence Cloud

Happy holidays from our team to yours!

Hi Community!  2018 was filled with changes for our team, both big and small, and we've taken a lot of time to both celebrate our wins and recognize areas of improvement. One thing that we're a...

86 views 0 11
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you