Content
View differences
Updated by Tobias Dillmann 27 days ago
> * We will have sprint sharing in the initial version.
>
> * It simplifies migration from versions and is what we want to have later on anyway.
>
> * A sprint will have the same status across all projects it is shared with.
>
> * Sprints can only be activated by a user having the `manage_sprints` permission in the project from which the sprint is shared.
>
> * Sprints can thus also only be activated in the sprint from which it is shared.
>
> * Trivial but for clarity: If the sprint is not shared, then it can only be activated in the project it is defined in.
>
> * This all results in that we currently cannot prevent the collision of two active sprints in the following case:
>
> * There is already an active sprint in the project.
>
> * A shared sprint is activated OR an active sprint is shared.
>
> * We can prevent the case where:
>
> * There is already a sprint (shared or not) active in the project
>
> * The user tries to activate another sprint in the project.
>
> * The case we cannot prevent is one we probably want to support later on anyway and have to deal with such a situation. As long as we don't have the notion of 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 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 having multiple possibly active sprints shared with the same project.
>
> * A solution might be to take away the possibility to mange sprints in projects 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 closer to the project < project)
>
>
> \-- copied from <mention class="mention" data-id="71242" data-type="work_package" data-text="#71242">#71242</mention> [comment](https://community.openproject.org/projects/stream-jira-agile-replacement/work_packages/71242/activity#comment-1625712)
<br>
<br>
>
> * It simplifies migration from versions and is what we want to have later on anyway.
>
> * A sprint will have the same status across all projects it is shared with.
>
> * Sprints can only be activated by a user having the `manage_sprints` permission in the project from which the sprint is shared.
>
> * Sprints can thus also only be activated in the sprint from which it is shared.
>
> * Trivial but for clarity: If the sprint is not shared, then it can only be activated in the project it is defined in.
>
> * This all results in that we currently cannot prevent the collision of two active sprints in the following case:
>
> * There is already an active sprint in the project.
>
> * A shared sprint is activated OR an active sprint is shared.
>
> * We can prevent the case where:
>
> * There is already a sprint (shared or not) active in the project
>
> * The user tries to activate another sprint in the project.
>
> * The case we cannot prevent is one we probably want to support later on anyway and have to deal with such a situation. As long as we don't have the notion of 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 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 having multiple possibly active sprints shared with the same project.
>
> * A solution might be to take away the possibility to mange sprints in projects 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 closer to the project < project)
>
>
> \-- copied from <mention class="mention" data-id="71242" data-type="work_package" data-text="#71242">#71242</mention> [comment](https://community.openproject.org/projects/stream-jira-agile-replacement/work_packages/71242/activity#comment-1625712)
<br>
<br>