Content
View differences
Updated by Attila Dombi 21 days ago
* Migrate existing Version-Sprints to new Sprint model
* Journal is written to inform user about the type change
<br>
> * Migration considerations:
>
> * Existing versions used as sprints are migrated (read copied).
>
> * The goal is to have an uninterrupted user experience when switching from the pre-sprint state to the post-sprint state.
>
> * A version is migrated to a sprint if
>
> * the version is configured to be displayed "left" (for "Column in backlog") in a project
>
> * Backlogs is active in that project
>
> * the version has at least one work package associated to it in that project
>
> * Name, start & finish date, status is migrated
>
> * Mapping of status
>
> * Version open -> Sprint in planning
>
> * Version locked or closed -> Sprint completed
>
> * The project the sprint is created in and the sharing it has:
>
> * The project furthest down the hierarchy with the sharing set to "subprojects" - if the sprint is used in multiple projects and they share the same hierarchy
>
> * Just the project where the sprint is used with the sharing set to "none" - if the sprint is only used in a single project.
>
> * The project having the "system-wide" version defined with the status set to systemwide - for a version shared system-wide.
>
> * The existing connection from a work package to a version is kept
>
> * The reason for this is that we cannot differentiate programmatically whether a version was only used as a sprint or if it also served the role of a version.
>
> * Work packages associated to a migrated version are associated to the created sprint.
>
> * A journal is written by the system user informing about the shift from version to sprint - no notification is sent
>
> * \[open\] Phrasing of the message
>
> * Permissions need to be migrated (see below)
>
<br>
Notes:
* Versions sharing defined in `app/models/versions/scopes/shared_with.rb`
* Mapping Versions to Sprints:
* Not Shared -> Not Shared
* With Subprojects -> With Subprojects
* With Project Hierarchy -> With Subprojects
* Simulate Hierarchy by finding the root Project and apply sharing with Subprojects. As a side effect, the sprint will be shared with the original Projects' sibling as well.
* With Project Tree -> With Subprojects
* Finding root Project, same as Hierarchy.
* All Projects -> All Projects
* Journal is written to inform user about the type change
<br>
> * Migration considerations:
>
> * Existing versions used as sprints are migrated (read copied).
>
> * The goal is to have an uninterrupted user experience when switching from the pre-sprint state to the post-sprint state.
>
> * A version is migrated to a sprint if
>
> * the version is configured to be displayed "left" (for "Column in backlog") in a project
>
> * Backlogs is active in that project
>
> * the version has at least one work package associated to it in that project
>
> * Name, start & finish date, status is migrated
>
> * Mapping of status
>
> * Version open -> Sprint in planning
>
> * Version locked or closed -> Sprint completed
>
> * The project the sprint is created in and the sharing it has:
>
> * The project furthest down the hierarchy with the sharing set to "subprojects" - if the sprint is used in multiple projects and they share the same hierarchy
>
> * Just the project where the sprint is used with the sharing set to "none" - if the sprint is only used in a single project.
>
> * The project having the "system-wide" version defined with the status set to systemwide - for a version shared system-wide.
>
> * The existing connection from a work package to a version is kept
>
> * The reason for this is that we cannot differentiate programmatically whether a version was only used as a sprint or if it also served the role of a version.
>
> * Work packages associated to a migrated version are associated to the created sprint.
>
> * A journal is written by the system user informing about the shift from version to sprint - no notification is sent
>
> * \[open\] Phrasing of the message
>
> * Permissions need to be migrated (see below)
>
<br>
Notes:
* Versions sharing defined in `app/models/versions/scopes/shared_with.rb`
* Mapping Versions to Sprints:
* Not Shared -> Not Shared
* With Subprojects -> With Subprojects
* With Project Hierarchy -> With Subprojects
* Simulate Hierarchy by finding the root Project and apply sharing with Subprojects. As a side effect, the sprint will be shared with the original Projects' sibling as well.
* With Project Tree -> With Subprojects
* Finding root Project, same as Hierarchy.
* All Projects -> All Projects