-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
-
JIRA 5.1.1
-
0
-
3
-
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
- mentioned in
-
Page Failed to load
[JSWSERVER-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.
Hello,
Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.
Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.
Please note the comments on this thread are not being monitored.
You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.
To learn more about our recent investments in Jira Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues, current work, and future plans.
Kind regards,
Jira Data Center