nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

with-schedule-issues.jpg

no-schedule-issues.jpg

Accepted answers

All comments

Ignacio Pulgar

Create and use a specific project role for those customers.
Grant them with at least Browse Projects and Create Issues permission.
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.

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.

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:

go to https://<YOURS>.atlassian.net/secure/project/ViewProjectRoles.jspa
add a project role with name "Customers" and click on the button "Add project role"
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
click on the button Actions > Edit Permissions, on the top-right corner
click on the button 'Grant permission' on the top-right corner
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
grant the permissions to the new "Customers" project role, and click on Grant
go to: https://<YOURS>.atlassian.net/plugins/servlet/project-config/<KEY>/roles
remove all customer user accounts from all other roles
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
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.

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 wink

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

jira-core