Content
Updated by Niels Lindenthal about 1 month 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:
1. * 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)
\[NL\] sound more reasonable to me than option 2.
2. * 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
\[NL\] The idea for lables (evolution of labels) is to share them like versions with subprojects. With versions we could add filters to the selection. Similar to quick filters in the main search. I guess we can address this separately (out of scope for now).
* \[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.
* \[NL\] Isn't this already the case, e.g. when I remove a user from a project or deactivate a type? I would suggest to handle this consisently.
* \[open\] should the available columns also be taken from all the projects?
* \[NL\] Yes, this makes sense to me.
* \[open\] should the available sort orders also be taken from all the projects?
* \[NL\] Not sure if I understand this correctly. Are you referring to the case when we are sorting by an attribute which is not available in all projects? In this case I would only sort the work packages that have this attribute. This can also be the case in a single project, e.g. by sorting by Assignee. Here we also can have work packages without a value.
* \[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.
* \[NL\] Good question: Would be consistent to have all filters. People could reduce the options by selecting specific projects. 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.
* \[NL\] Good point. I like the proposed approach. Would be strange if filters are destroyed when saved by the wrong person.
**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:
1.
\[NL\] sound more reasonable to me than option 2.
2.
* \[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
\[NL\] The idea for lables (evolution of labels) is to share them like versions with subprojects. With versions we could add filters to the selection. Similar to quick filters in the main search. I guess we can address this separately (out of scope for now).
* \[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.
* \[NL\] Isn't this already the case, e.g. when I remove a user from a project or deactivate a type? I would suggest to handle this consisently.
* \[open\] should the available columns also be taken from all the projects?
* \[NL\] Yes, this makes sense to me.
* \[open\] should the available sort orders also be taken from all the projects?
* \[NL\] Not sure if I understand this correctly. Are you referring to the case when we are sorting by an attribute which is not available in all projects? In this case I would only sort the work packages that have this attribute. This can also be the case in a single project, e.g. by sorting by Assignee. Here we also can have work packages without a value.
* \[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.
* \[NL\] Good question: Would be consistent to have all filters. People could reduce the options by selecting specific 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.
* \[NL\] Good point. I like the proposed approach. Would be strange if filters are destroyed when saved by the wrong person.