Content
View differences
Updated by Parimal Satyal about 4 years ago
This work package extends <mention class="mention" data-id="40330" data-type="work_package" data-text="#40330">#40330</mention>, which describes the behaviour of the generic "Include projects" function when it is available on the main toolbar.
This feature describes how this module should adapt to specificities concerning the Team Planner. At this point, the goal is to discuss the following open questions so we are able to define the acceptance criteria for 12,1:
### Context
* A team planner "belongs" to a project. By default (without include projects), the assignees and work packages visible to the module are limited to the scope of the project.
* This means that any member of the project can be added as an assignee row to the Team planner.
* For each each assignee, the team planner only displays the work packages assigned to them in the parent (_current)_ project. Work packages assigned to the same user in other projects will not be displayed.
* With Include Projects, the scope is extended and must meet these acceptance criteria:
### **Acceptance criteria**
_Work in progress._
* Adding other projects via the include project dialogue _will not_ change the scope of the assignees that can be added to the team planner; this is limited by the users in the parent project.
* For each assignee, the team planner will _also_ view display work packages that they are assigneed to in the included project(s).
* Removing these included projects will then also remove these work packages.
* Work packages from other projects are more likely to have resctrictions in terms of assignee changes (depending on which user is attempting the modification), so on drag start:
* Indicate which assignees are _unable_ to receive dragged work package by providing a visual reference (a red highlight). highlight or dimmed overlay over invalid assignees).
* _**Note:** the limits of how we can provide this visual feedback is currently being explored by the dev team; Product will provide mockup once we have more clarity._
* This might need extending API capability.
* The determination of which assignees can "receive" which work packages should ideally determined pre-drag, in a way that reduces visible lag.
* _**Note:** One proposition being explored is the possibility to determine this after initial drawing of the team planner but before any drag has started. Devs will need to explore the optimal way to determine this._
### Archive of discussed open questions
Please note that the following is here only so archive past discussions so we don't lose context around decisions that we made. The acceptance criteria already include all relevant information and the following can be ignored for implementation/QA.
* **Open Question 1:** Do we limit the assignees that can be added a team planner to members of the parent project but allow users to _also_ view work packages for those assignees from included project(s); or do we also want to afford the user the ability to also add assignee rows of included projects (who are not members of hte parent project)?
* **Answer:** The assignees are limited to the parent project.
* Work packages that are displayed in the team planner but are from included projects have fewer degrees of freedom, depending on the permissions for that each user. For example, a user might be able to drag a work package to Assignee X but not to Assignee Y, because Assignee Y is not a member of that included project. We would need to find a way to communicate this, but it would probably involve highlighting "available" drop zones within the calendar on drag.
* **Open Question 2:** Any ideas on how we could deal with this?
* **Answer:** Technically, it _could_ be possible to highlight assignees that could "receive" a dragged work package (or the inverse, identify which assignees cannot receive). To be explored technically. (This could also apply within the same project hierarchy, outside of _Include projects_).
* Needs API capability.
* Might be that it's not technically feasible to alter, visually, how fullcalendar can show it.
* ~~If we allow adding assignees from included projects, we would have to decide what happens if then subsequently un-includes that project?~~
* ~~**Open question 3:** Do the added assignees from that other project disappear? Or do they stay but only work packages from the current project (and perhaps~~ _~~other~~_ ~~included projects, if there's an overlap) be displayed?~~
* ~~Given that the include projets function is presented as a non-destructive (or a view-level) functionality, we have to keep in mind that the user won't expect inclusion of a project to cause structural changes to the team planner.~~
* **Open question 4:** How much of this is feasible with the current API? For things that are not yet possible, how practical is it to extend the API to make it possible?
* **Answer:** There might be additional overhead (i.e, longer loading time at the start), but nothing to significant on top of what we already have.
* Might be able to define constraints dynamically, in which case, delay would on drag. But, from a UX pov, it's better to reduce delay on drag (else, appears to be an error from user pov).
* Alternatively, before once starts drag/drop but _after_ loading the actual calendar = ideal (if possible, tbd).
* ~~**Open quesiton 5:** What kind of performance overhead would such additional features add? (This is especially relevant given that the Team Planner is not the snappiest beast quite yet).~~
* **Open question 6**: What happens to members who are no longer part of a project? (So far, guess: that assignee row will be removed; needs to be specified).
* **Answer:** A user removed from a project should also be removed from the team planner list of assigneed.
* Currently, a removed user is indeed removed from the assignee row (although technically, the WPs are still assigned to this user, despite their no longer being a part of the project).
* For later, we need to maybe work on feedback asking users what to do concering WPs currently assigned to a member one is trying to remove. We probably need a UI element indicate this ghost/orphaned state.
###
This feature describes how this module should adapt to specificities concerning the Team Planner. At this point, the goal is to discuss the following open questions so we are able to define the acceptance criteria for 12,1:
### Context
* A team planner "belongs" to a project. By default (without include projects), the assignees and work packages visible to the module are limited to the scope of the project.
* This means that any member of the project can be added as an assignee row to the Team planner.
* For each each assignee, the team planner only displays the work packages assigned to them in the parent (_current)_ project. Work packages assigned to the same user in other projects will not be displayed.
* With Include Projects, the scope is extended and must meet these acceptance criteria:
### **Acceptance criteria**
_Work in progress._
* Adding other projects via the include project dialogue _will not_ change the scope of the assignees that can be added to the team planner; this is limited by the users in the parent project.
* For each assignee, the team planner will _also_ view display work packages that they are assigneed to in the included project(s).
* Removing these included projects will then also remove these work packages.
* Work packages from other projects are more likely to have resctrictions in terms of assignee changes (depending on which user is attempting the modification), so on drag start:
* Indicate which assignees are _unable_ to receive dragged work package by providing a visual reference (a red highlight).
* _**Note:** the limits of how we can provide this visual feedback is currently being explored by the dev team; Product will provide mockup once we have more clarity._
* This might need extending API capability.
* The determination of which assignees can "receive" which work packages should ideally determined pre-drag, in a way that reduces visible lag.
* _**Note:** One proposition being explored is the possibility to determine this after initial drawing of the team planner but before any drag has started. Devs will need to explore the optimal way to determine this._
### Archive of discussed open questions
Please note that the following is here only so archive past discussions so we don't lose context around decisions that we made. The acceptance criteria already include all relevant information and the following can be ignored for implementation/QA.
* **Open Question 1:** Do we limit the assignees that can be added a team planner to members of the parent project but allow users to _also_ view work packages for those assignees from included project(s); or do we also want to afford the user the ability to also add assignee rows of included projects (who are not members of hte parent project)?
* **Answer:** The assignees are limited to the parent project.
* Work packages that are displayed in the team planner but are from included projects have fewer degrees of freedom, depending on the permissions for that each user. For example, a user might be able to drag a work package to Assignee X but not to Assignee Y, because Assignee Y is not a member of that included project. We would need to find a way to communicate this, but it would probably involve highlighting "available" drop zones within the calendar on drag.
* **Open Question 2:** Any ideas on how we could deal with this?
* **Answer:** Technically, it _could_ be possible to highlight assignees that could "receive" a dragged work package (or the inverse, identify which assignees cannot receive). To be explored technically. (This could also apply within the same project hierarchy, outside of _Include projects_).
* Needs API capability.
* Might be that it's not technically feasible to alter, visually, how fullcalendar can show it.
* ~~If we allow adding assignees from included projects, we would have to decide what happens if then subsequently un-includes that project?~~
* ~~**Open question 3:** Do the added assignees from that other project disappear? Or do they stay but only work packages from the current project (and perhaps~~ _~~other~~_ ~~included projects, if there's an overlap) be displayed?~~
* ~~Given that the include projets function is presented as a non-destructive (or a view-level) functionality, we have to keep in mind that the user won't expect inclusion of a project to cause structural changes to the team planner.~~
* **Open question 4:** How much of this is feasible with the current API? For things that are not yet possible, how practical is it to extend the API to make it possible?
* **Answer:** There might be additional overhead (i.e, longer loading time at the start), but nothing to significant on top of what we already have.
* Might be able to define constraints dynamically, in which case, delay would on drag. But, from a UX pov, it's better to reduce delay on drag (else, appears to be an error from user pov).
* Alternatively, before once starts drag/drop but _after_ loading the actual calendar = ideal (if possible, tbd).
* ~~**Open quesiton 5:** What kind of performance overhead would such additional features add? (This is especially relevant given that the Team Planner is not the snappiest beast quite yet).~~
* **Open question 6**: What happens to members who are no longer part of a project? (So far, guess: that assignee row will be removed; needs to be specified).
* **Answer:** A user removed from a project should also be removed from the team planner list of assigneed.
* Currently, a removed user is indeed removed from the assignee row (although technically, the WPs are still assigned to this user, despite their no longer being a part of the project).
* For later, we need to maybe work on feedback asking users what to do concering WPs currently assigned to a member one is trying to remove. We probably need a UI element indicate this ghost/orphaned state.
###