Content
View differences
Updated by Parimal Satyal about 3 years ago
### Context
Today, the filter button in a work package index (in Table, List or Cards view) works as an expand.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/53692/content"> src="/api/v3/attachments/53524/content">
The current approach has a number of disadvantages:
* it takes more horizontal space than necessary and can take a lot of vertical space
* when there are lot of criteria, the expand can fill up the entire viewport
* it is a non-standard UI component and behaves differently than is different the other button that affects filter criteria (i.e, Include projects)
* filters are applied immediately with every new criteria, vs with an "Apply" button once the user has selected all the necessary criteria, which has a performance overhead (since a new query is made with every change)
This feature aims to fix these three issues by replacing the filter expand with a filder drop modal.
### **Acceptance criteria**
**<img class="op-uc-image op-uc-image_inline" style="width:783px;" src="/api/v3/attachments/53525/content">**
* On non-mobile devices, clicking on the "Filters" button displays a drop modal:
* Width: 630px
* **\[open\]** or should the width depend on available space?
* Max-height: 80% of view port
* If the content overflows, the modal will allow scroll between the header and the action bar.
* The drop modal is composed of these components:
* A header, with the title "Filter"
* The same filter options as today
* An action bar (grey background) with two buttons:
* Apply (primary)
* Clear (secondary)
* The selected filters are not applied till the user clicks on the "Apply" button.
* The button closes the modal and applies the filters to the current view.
* The "Clear" button clears all filter options on the open modal,
* it reinitalises it to the default filter state (only 1 active: status == open).
* the reinitialised filter criteria are not applied immediately; the user has to then click on "Apply"
* if the user closes the modal by clicking outside of the modal _before_ clicking "Apply", the changes are not applied
* On mobile devices, the modal behaves as drop-modals normally do and take the full screen.
### Out of scope
* This feature does not change or update the actual filtering mechanism, only the behaviour of the _container_ and the point at which it is applied is modified.
* The filter tab in the work package configuration form will remain unchanged.
Today, the filter button in a work package index (in Table, List or Cards view) works as an expand.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/53692/content">
The current approach has a number of disadvantages:
* it takes more horizontal space than necessary and can take a lot of vertical space
* when there are lot of criteria, the expand can fill
* it is a non-standard UI component and behaves differently than
* filters are applied immediately with every new criteria, vs with an "Apply" button once the user has selected all the necessary criteria, which has a performance overhead (since a new query is made with every change)
This feature aims to fix these three issues by replacing the filter expand with a filder drop modal.
### **Acceptance criteria**
**<img class="op-uc-image op-uc-image_inline" style="width:783px;" src="/api/v3/attachments/53525/content">**
* On non-mobile devices, clicking on the "Filters" button displays a drop modal:
* Width: 630px
* **\[open\]** or should the width depend on available space?
* Max-height: 80% of view port
* If the content overflows, the modal will allow scroll between the header and the action bar.
* The drop modal is composed of these components:
* A header, with the title "Filter"
* The same filter options as today
* An action bar (grey background) with two buttons:
* Apply (primary)
* Clear (secondary)
* The selected filters are not applied till the user clicks on the "Apply" button.
* The button closes the modal and applies the filters to the current view.
* The "Clear" button clears all filter options on the open modal,
* it reinitalises it to the default filter state (only 1 active: status == open).
* the reinitialised filter criteria are not applied immediately; the user has to then click on "Apply"
* if the user closes the modal by clicking outside of the modal _before_ clicking "Apply", the changes are not applied
* On mobile devices, the modal behaves as drop-modals normally do and take the full screen.
### Out of scope
* This feature does not change or update the actual filtering mechanism, only the behaviour of the _container_ and the point at which it is applied is modified.
* The filter tab in the work package configuration form will remain unchanged.