It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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


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?



2 answers

0 votes
Ignacio_Pulgar Community Leader Nov 10, 2016
  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. 

Ignacio_Pulgar Community Leader Nov 11, 2016

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

Ignacio_Pulgar Community Leader Nov 11, 2016

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.

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

Ignacio_Pulgar Community Leader Nov 11, 2016

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:

Ignacio_Pulgar Community Leader Nov 11, 2016

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


Cool :thumbs-up:

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Core

How to manage many similar workflows?

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

2,701 views 11 5
Join discussion

Community Events

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

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you