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 &quot;Include projects&quot; function when it is available on the main Begin of the insertiontoolbar.End of the insertion Begin of the deletion toolbar. End of the deletion

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:

### Things to consider

* Team Planner &quot;belongs&quot; to a project. By default, the assignees and work packages visible to the Team Planner 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 Begin of the insertionplanner.End of the insertion Begin of the deletion planner. End of the deletion
* For each each assignee, team planner only displays the work packages assigned to them in the _current_ Begin of the insertionproject.End of the insertion Begin of the deletion project. End of the deletion
* With Include Projects, we could potentially:
* For each assignee, _also_ view display work packages that they are assigneed to in the included project(s)
* Be _also_ able to add assignees to the board that are members of the included project(s)
* **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)? Begin of the insertion
* **Answer:** The assignees are limited to the parent project.End of the insertion

### Possible complications to discuss

* 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 &quot;available&quot; drop zones within the calendar on drag.
* **Open Question 2:** Any ideas on how we could deal with this? Begin of the insertion
End of the insertion Begin of the deletion


End of the deletion * Begin of the insertion**Answer:** Technically, it _could_ be possible to highlight assignees that could &quot;receive&quot; 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&#39;s not technically feasible to alter, visually, how fullcalendar can show it.
* ~~IfEnd of the insertion Begin of the deletion IfEnd of the deletion we allow adding assignees from included projects, we would have to decide what happens if then subsequently un-includes that Begin of the insertionproject?~~End of the insertion Begin of the deletion project?End of the deletion
* Begin of the insertion~~**OpenEnd of the insertion Begin of the deletion **OpenEnd of the deletion question 3:** Do the added assignees from that other project disappear? Or do they stay but only work packages from the current project (and Begin of the insertionperhaps~~ _~~other~~_ ~~includedEnd of the insertion Begin of the deletion perhaps _other_ includedEnd of the deletion projects, if there&#39;s an overlap) be Begin of the insertiondisplayed?~~End of the insertion Begin of the deletion displayed? End of the deletion
* Begin of the insertion~~GivenEnd of the insertion Begin of the deletion GivenEnd of the deletion 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&#39;t expect inclusion of a project to cause structural changes to the team Begin of the insertionplanner.~~
End of the insertion Begin of the deletion planner.


End of the deletion * **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 Begin of the insertionpossible?
End of the insertion Begin of the deletion possible? 


End of the deletion * Begin of the insertion**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&#39;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).
* ~~**OpenEnd of the insertion Begin of the deletion **OpenEnd of the deletion 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 Begin of the insertionyet).~~
* **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.End of the insertion Begin of the deletion yet).End of the deletion

### **Acceptance criteria**

_Work in progress. Will be defined once we have more clarity._