Content
View differences
Updated by Jens Ulferts about 2 years ago
**As a** project member that is working in multiple projects
**I want to** have all filters from all selected projects (include projects)
**so that** I can filter across multiple projects.
**Acceptance criteria**
* The available filters are the combined set of all filters and filter options from all selected projects.
* \[open\] Filter values, either:
* Use the union of all possible values as allowed filter values (e.g. for an assignee filter, allow every user that is a member in at least one project currently included. For a type filter, allow every type that is used in at least one project currently included)
* Always allow all values (e.g. for an assignee filter, allow every user in the instance. For a type filter, allow all types)
* \[open\] conflicting filter values would require the filter values to be displayed differently to make them discernible, e.g.
* in case multiple versions have the same name, they would be harder to differentiate (could also happen now but it is less likely to happen)
* In case multiple categories have the same name, they would be harder to differentiate
* \[open\] in case the union of possible filter values (see above) from the included projects is used, how to handle the removal of projects that in turn lead to the removal of filter values the user already selected. They could be marked requiring the user to remove them, removed automatically or silently ignored.
* \[open\] should the available columns also be taken from all the projects?
* \[open\] should the available sort orders also be taken from all the projects?
* \[open\] How to handle the case, when no project is chosen? That is the same case as the current global work package list. We could allow all the filters and filter values from all existing projects.
* \[open\] the problem of different permissions sets would become more likely to happen. A user opening a query created by a different user might not have access to all the projects that were included. Both, the filtering results as well as the behaviour on that user modifying and saving the query anew would need to be defined. Probably best solution: Keep all the filters the user has had not access to see instead of dropping them on the save. The behaviour for filter values is harder to define but it might be sensible to keep all the filter values (even those the user did not see) unless new filter values were chosen. This could still lead to the user unknowingly removing filter values.
* The considerations here would suggest that at least the validation checks should not bail on filters/filter values that previously existed.
**I want to** have all filters from all selected projects (include projects)
**so that** I can filter across multiple projects.
**Acceptance criteria**
* The available filters are the combined set of all filters and filter options from all selected projects.
* \[open\] Filter values, either:
* Use the union of all possible values as allowed filter values (e.g. for an assignee filter, allow every user that is a member in at least one project currently included. For a type filter, allow every type that is used in at least one project currently included)
* Always allow all values (e.g. for an assignee filter, allow every user in the instance. For a type filter, allow all types)
* \[open\] conflicting filter values would require the filter values to be displayed differently to make them discernible, e.g.
* in case multiple versions have the same name, they would be harder to differentiate (could also happen now but it is less likely to happen)
* In case multiple categories have the same name, they would be harder to differentiate
* \[open\] in case the union of possible filter values (see above) from the included projects is used, how to handle the removal of projects that in turn lead to the removal of filter values the user already selected. They could be marked requiring the user to remove them, removed automatically or silently ignored.
* \[open\] should the available columns also be taken from all the projects?
* \[open\] should the available sort orders also be taken from all the projects?
* \[open\] How to handle the case, when no project is chosen? That is the same case as the current global work package list. We could allow all the filters and filter values from all existing projects.
* \[open\] the problem of different permissions sets would become more likely to happen. A user opening a query created by a different user might not have access to all the projects that were included. Both, the filtering results as well as the behaviour on that user modifying and saving the query anew would need to be defined. Probably best solution: Keep all the filters the user has had not access to see instead of dropping them on the save. The behaviour for filter values is harder to define but it might be sensible to keep all the filter values (even those the user did not see) unless new filter values were chosen. This could still lead to the user unknowingly removing filter values.
* The considerations here would suggest that at least the validation checks should not bail on filters/filter values that previously existed.