General approach

This story is meant to address the following needs:

• One or several Product Owners of "Upper backlog" are allowed to change priorities at higher level
• At "lower level" (for instance, sprint backlog), developers are allowed to change priorities but this should be limited to the scope of the sprint
• The change at sprint level do have an impact at release or product level (if Story A is moved before Story B in a sprint, it will also be the case at Product level) but the changes are limited to the stories that are part of the sprint

Acceptance criteria:

• Permissions are managed at Planning level
  • Each planning (Product, Release, Sprint, ...) has a group of people allowed to change priorities
  • By default, project members are allowed
  • The permission is exported/imported with XML template
  • The permission is inherited on project clone
• Permissions are applied on cascade according to hierarchy. Example:
  • "product_owners" group has "priority change" permission on Release backlog
  • "scrum_masters" group has "priority change" permission on Sprint backlog
  • Release is parent of Sprint
  • Then, "product_owners" can change priorities in both Release and Sprint backlogs
  • But "scrum_masters" can only change priorities in Sprint backlog
• The permission that apply on first planning (example Product planning when you have Products -> Releases -> Sprints) also apply on Project backlog (aka. Top Backlog)

Edge cases:

• When dashboard is configured to manage 2 kind of children, like:
  • Product (backlog types: story, note)
    • Release (backlog type: story)
    • Info (backlog type: note)
  • With 3 plannings:
    • Product planning: manage "story" and "note" in "Product"
    • Release planning: manage "story" in "Release"
    • Info planning: manage "note" in "Info"
• Then, permissions on both Release planning and Info planning are required to rank stories or notes in Product backlog