Content
View differences
Updated by Parimal Satyal 11 months ago
**Context**
The first place we'll "test" the use of this new [FilterableTreeView](https://community.openproject.org/wp/63717) component will be in admin settings pages as a way of selecting projects in which to enable a certain object, like a project attribute, type or custom field. We'll start with Project attributes:
**Acceptance criteria**
In Administration → Projects → Project attributes → {one attribute} → Projects tab:
* **Toolbar:** There is a toolbar containing
* On the left side,
* A SegmentedControl sets users pick between: **All** and **Selected**
* A filter-by-text search bar
* Title: "**Filter by text**"
* On the right side,
* An "**Include all sub-projects**" checkbox.
* Checking this will auto-check all sub-projects when checking a parent project
* **Project list:** There is a TreeView representation of the project hierarcht below the toolbar:
* In "All" view,
* The TreeView lists all projects in the instance
* By default, all nodes are collapsed; the user can manually expand/collapse the project hierarchy to select projects in to which they want to enable this project attribute
* If the list already has projects that have been enabled, they will be visible by default; this means that if enabled projects are at an n+4 level, all those parent nodes will be expanded by default
* In "Selected" view,
* The TreeView lists only those projects that have been selected
* The hierarchy of the selected projects will be visible
* When filtering by text,
* The TreeView lists only those projects that match the selected terms
* The hierarchy of the selected projects will be visible in grey,
* \[open\] But not disabled; the user is free to select the parent too
* **Scroll/viewport:** the primary Save save button should always be visible at the bottom of the page
* If the project list is particularly long, it will have to be scrolled within a contained area above this Save button
**Technical notes**
* <br>
**Permissions and visibility considerations**
* _\-_
**Translation considerations**
* _\-_
**Out of scope**
* After this first implementation, this same component will also be used elsewhere where we have a project selector:
* Custom fields
* Types
* Admin → API and webhooks → Webhooks
* ...
* An ability to select/unselect all <br>
The first place we'll "test" the use of this new [FilterableTreeView](https://community.openproject.org/wp/63717) component will be in admin settings pages as a way of selecting projects in which to enable a certain object, like a project attribute, type or custom field. We'll start with Project attributes:
**Acceptance criteria**
In Administration → Projects → Project attributes → {one attribute} → Projects tab:
* **Toolbar:** There is a toolbar containing
* On the left side,
* A SegmentedControl sets users pick between: **All** and **Selected**
* A filter-by-text search bar
* Title: "**Filter by text**"
* On the right side,
* An "**Include all sub-projects**" checkbox.
* Checking this will auto-check all sub-projects when checking a parent project
* **Project list:** There is a TreeView representation of the project hierarcht below the toolbar:
* In "All" view,
* The TreeView lists all projects in the instance
* By default, all nodes are collapsed; the user can manually expand/collapse the project hierarchy to select projects in to which they want to enable this project attribute
* If the list already has projects that have been enabled, they will be visible by default; this means that if enabled projects are at an n+4 level, all those parent nodes will be expanded by default
* In "Selected" view,
* The TreeView lists only those projects that have been selected
* The hierarchy of the selected projects will be visible
* When filtering by text,
* The TreeView lists only those projects that match the selected terms
* The hierarchy of the selected projects will be visible in grey,
* \[open\] But not disabled; the user is free to select the parent too
* **Scroll/viewport:** the primary Save
* If the project list is particularly long, it will have to be scrolled within a contained area above this Save button
* <br>
**Permissions and visibility considerations**
* _\-_
**Translation considerations**
* _\-_
**Out of scope**
* After this first implementation, this same component will also be used elsewhere where we have a project selector:
* Custom fields
* Types
* Admin → API and webhooks → Webhooks
* ...
* An ability to select/unselect all