well github is where im currently resoloving some stuff there as well but ya im only one man so i appologize so many questions to awnser i really didnt think nothin of wat i did found a digital point in cookie browsing like i did when i was 12 lol just seeing if i got something good like mining lol

all i did was get on here with the masters and look into my question and blam pretty self explanitory expecially for me with no expierince n just a open mind any thing is possible

the names randee hoke sorry guys i really did this just messing aroud in wiki nad firefox nad yeah download safari and windows and my phone and use the xfinitywifi signal

also before iwas on gateway buisness wifi

i am the user and the computer was my sons i was bored jobless and depressed n just took intrest the last month but ya but i fixed and resolved that diagram pretty simple really the names randee hoke rhoke39@gmail.com

and i took over owner dont ask me how admin i put in work lol but i still have admin but can bypass with the windows

This would be a very useful feature. I'm all for it as it would enhance sprint backlogs greatly and reduce the overhead of work-arounds(dragging issues across projects). It will also encourage/help collaboration between different teams/projects.

I agree with you Matti, however, this is what was mentioned in the comment as the solution. My real problem is that the action should NOT be linked to the Schedule issue permission (as it is now), as this controls the right to edit/view the due date. Hence, connecting it to Manage Sprint permission, I could give this permission to all project members, and still have external users editing the due date, without having the right to add/remove issues from the sprint.

There are different views on this and some Jira users like me prefer the open approach where the team members are allowed in the tool to do this without the need to request the scrum master to do it. This is especially important when your team switches scrum master often. Therefore it would not be good from my view to link adding issues to a sprint into this permission.

We are using JIRA Server 7.1.9. However, users with Schedule Issue but WITHOUT Manage Sprint permission, are still allowed to add issues to the active sprint.
So if this issue was suppose to fix this problem also (as mentioned in multiple comments), it is still not fixed and should be reopened.

Hi paul.thomas1 - the origin board based permissions are in place, they are in the Server 7.1 release and also Cloud.
Further updates would be either in the documentation space, release notes or other related issues here on JIRA.Atlassian.com
Below are links to the documentation for permissions:
Server: https://confluence.atlassian.com/display/JIRASOFTWARESERVER071/Permissions+overview
Cloud: https://confluence.atlassian.com/jirasoftwarecloud/permissions-overview-764478244.html

To better understand your questions for the behaviour above, could you please create a support ticket at https://support.atlassian.com
That way we can provide you with support specific to your circumstances and with higher security. The credentials to access the Support site should be the same as this one (jira.atlassian.com).

Kind regards,
Martin
JIRA Software

Hi @mjopson,

In your comment, under "Consistent Permissions", you mention that this feature will move to all sprint related permissions being based on the projects visible under a board's filter. I've just been experimenting with JIRA Software 7.1.0#71003 and this doesn't appear to be the case. A couple of specific things I have noticed, for a Scrum board looking at two projects (i.e. board filter is "project in (PROJA, PROJB) ORDER BY Rank"):

1. If "User A" has all permissions in PROJA but none in PROJB, they can still create sprints on the board (it seems the list of projects checked is based on those the current user can see). If User A is granted Browse Project permissions in PROJB (but nothing else) then they cannot create sprints (I have PROJB issues in the Backlog, I haven't checked if this is still the case if I remove them).
2. Sprint start/stop permissions still seem to be based on the issues added to that sprint, i.e. User A can start/stop a sprint on the above board provided no PROJB issues are in the sprint.

Have the "origin board" based plans been abandoned? Or will they be in a later release? And is this the best place to keep an eye out for updates?

Thanks very much,

Paul