-
Suggestion
-
Resolution: Timed out
-
None
-
JIRA 5.1.1
-
2
-
This is something I found randomly and I guess it makes sense for us to check. I tried this on a clean installation and reproduced many times in different ways. In a nutshell, I think the shortest path to demonstrate is the following:
- Let us say I have a project named ABC and a Rapid Board ABC Board containing issues from that project.
- I also have two users:
- charlie: All permissions on project ABC
- alpha: Only in jira-users, essentially only able to create issues in ABC (user has been added specifically in this example but it would work for him anyway):
- Project roles in ABC are like the following:
- charlie creates ABC-1:
- Then charlie adds ABC-1 to Sprint 1 (just created by him, also):
- The sprint id for that sprint is 1 (the address bar is from the sprint report):
- The Sprint field is also visible on all screens:
- Now user alpha tries to create an issue in JIRA. Remember that he cannot even browse project ABC but he can edit the Sprint Field and add the sprint id (1, in this case):
- ... so when he tries to view ABC-2 he cannot:
- However, ABC-2 has been added to the sprint:
Should this be possible? Am I missing something, perhaps?
- relates to
-
- Gathering Interest
- was split into
-
- Closed
-
- Closed
[JSWCLOUD-6037] Restrict editing of the Sprint CF to users with Schedule permission for that issue
We have also just found this exact scenario. What we have come up with is that if user creates an issue for a project that they have Schedule Issue permissions in, they can associate the issue to any Sprint (active or future) that is available in the Jira instance.
This problem have caused us some problem. Cause when a issue does not belong to one project has been added to the project's sprint. The project's PO won't be able to close the sprint since he doesn't have the right of the issue's project. I have a support ticket about this here: https://support.atlassian.com/servicedesk/customer/ghs/configuration-query-13029
Nikhil Gupta
added a comment - Few in my team have figured this out and this is now becoming a problem for us. Good that you have already figured this out and are working on this. A quick solution would help us. 
Nikhil Gupta
added a comment - Few in my team have figured this out and this is now becoming a problem for us. Good that you have already figured this out and are working on this. A quick solution would help us. So it turns out that the regular way of adding issues to sprints (drag and drop on Plan Mode), does not require any special permission currently. All you need is the Edit Issue permission.
To bring this bug (which is actually a story) into the next release now, without fixing the aforementioned case, would create an inconsistent experience.
I propose we keep this work on a branch but do not bring it into the next version. We will add a related story to complete the work for the other case, do thorough testing, and then release all related features at once.
Andreas Ebbert-Karroum
added a comment - Hi,
interesting observation. Actually I would like to have a feature like this. I'd like for my developers to be able to add new tasks for themselves in their scrum task board, without having the schedule issue permission. People, who are not even able to browse the project certainly shouldn't be able to do that.
Andreas
Andreas Ebbert-Karroum
added a comment - Hi,
interesting observation. Actually I would like to have a feature like this. I'd like for my developers to be able to add new tasks for themselves in their scrum task board, without having the schedule issue permission. People, who are not even able to browse the project certainly shouldn't be able to do that.
Andreas Thanks for the input, sclowes. There is no connecting SAC issue. I just reproduced this in a local installation and it felt strange that it was possible.
I believe (have not verified) that in JIRA you are not allowed to modify the Fix Version if you do not have Schedule Permission. We could do the same when validating input for the Sprint field.
Don't think there's much we can do about this, it's the nature of how sprints work. We'd need to refuse the field edit based on the user, which I don't believe it possible.
Is this a customer reported issue? There's no SAC case included.
Hi everyone,
Thank you for bringing this suggestion to our attention. As explained in our new feature policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritise and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.
Unfortunately, as a result of inactivity for an extended period of time, this suggestion didn’t make it to the roadmap and we are closing it.
While this issue has been closed, our Product Managers continue to look at requests on jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.
Thank you again for providing valuable feedback to our team - Jira Cloud Product Management