Content
View differences
Updated by Jens Ulferts 22 days ago
> * Sharing is a project-level setting, not a sprint-level one (like with versions at the moment). Users can choose We will have sprint sharing in the project settings: initial version.
>
> * Share sprints - Sprints can be created in this project. All those created sprints are shared It simplifies migration from versions and is what we want to either (user selection): have later on anyway.
>
> * All A sprint will have the same status across all projects it is shared with.
>
> * Subprojects Sprints can only be activated by a user having the `manage_sprints` permission in the project from which the sprint is shared.
>
> * No sharing - Sprints can thus also only be created activated in this project. None of the created sprints are shared with any other project sprint from which it is shared.
>
> * Receive shared sprints - No sprints Trivial but for clarity: If the sprint is not shared, then it can only be created within this project. Instead shared activated in the project it is defined in.
>
> * This all results in that we currently cannot prevent the collision of two active sprints are used. in the following case:
>
> * There is already an active sprint in the project.
>
> * Status, Name and dates of a A shared sprint are also shared (can't be different per project) is activated OR an active sprint is shared.
>
> * Only one project We can "Share with all projects". prevent the case where:
>
> * \[open\] Possibly, define systemwide sprints not within There is already a sprint (shared or not) active in the project but outside of it. It could then be guarded by a global permission.
>
> * Sprint sharing is only possible if enabled first The user tries to activate another sprint in the instance administration project.
>
> * Only sprints from The case we cannot prevent is one sharing project are received. If there are multiple projects from which we probably want to support later on anyway and have to deal with such a receiving project could take its sprints situation. As long as we don't have the order notion of priority an "active" sprint anyway (with automatism in place for board generation) this might not be an immediate problem.
>
>
> Addendum:
>
> * We also cannot prevent it in the case where a sprint is as follows (lowest first shared with its sub-projects and then, in a project above, another sprint is shared with that project's sub-projects. That leads to highest priority): having multiple possibly active sprints shared with the same project.
>
> * All A solution might be to take away the possibility to mange sprints in projects sharing
that have a sprint shared with them. Because probably, it will not be the only sprint from the same source but rather, that all sprints are defined from there. 
>
So it might a setting in the project, not in the sprint, whether all of its sprints are shared.
> * If there is a conflict between two shared sprint setting, the one closer to the project would win (Systemwide < Sub-projects < Subproject sharing higher up closer to the ancestor chain project < project)
>
Copied
>
> \-- copied from <mention class="mention" data-id="70496" data-id="71242" data-type="work_package" data-text="###70496">###70496</mention> data-text="#71242">#71242</mention> [comment](https://community.openproject.org/projects/stream-jira-agile-replacement/work_packages/71242/activity#comment-1625712)
<br>
<br>
>
> * Share sprints - Sprints can be created in this project. All those created sprints are shared
>
> * All
>
>
>
>
> * This all results in that we currently cannot prevent the collision of two active
>
> * There is already an active sprint in the project.
>
>
>
>
> * \[open\] Possibly, define systemwide sprints not within
>
>
>
>
>
> Addendum:
>
> * We also cannot prevent it in the case where a sprint
>
> * All
>
Copied
>
> \-- copied
<br>
<br>