Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0.0-b5
-
Fix Version/s: 4.10.0-b1
-
Component/s: Staff Interface
-
Labels:None
-
Epic Link:
Description
The Package listing can become quite unruly and difficult to find the right thing. Add a filter option for Packages, which would consist of:
- A new button using the Font Awesome fa-filter funnel icon to the left of the + (New Package) button
- Clicking the button will toggle open/closed the filter section which appears above the table listing
- Filter by Module (dropdown), and Package Name (text field), which automatically filters the results in the table below
See attached screenshot. We'll need to import additional bootstrap styles including form-group, and form-control. Put each element in a col-md-3 column so that it will support up to 4 options.
Issue Links
- is blocked by
-
CORE-3542
Update widget helpers to support filters
-
- Closed
-
Activity
Yes, the widget would need to be able to support it. If the widget system needs to be updated, support should be optional. Not all widgets will have a filter option, but if a widget does it will need to render the filter toggle icon in the window decoration, which will toggle the display of the filter field section (Animate down/up if possible with jQuery), and widgets will have different filter fields.
Since we are using bootstrap columns, it may make sense to be able to specify the size/width of the columns. The task specifies allowing up to 4 fields (col-md-3) but it may be useful to be able to use a col-md-2 for 6 fields, etc. It looks best if they all fit on a single row.
Paul Phillips
added a comment - Yes, the widget would need to be able to support it. If the widget system needs to be updated, support should be optional. Not all widgets will have a filter option, but if a widget does it will need to render the filter toggle icon in the window decoration, which will toggle the display of the filter field section (Animate down/up if possible with jQuery), and widgets will have different filter fields.
Since we are using bootstrap columns, it may make sense to be able to specify the size/width of the columns. The task specifies allowing up to 4 fields (col-md-3) but it may be useful to be able to use a col-md-2 for 6 fields, etc. It looks best if they all fit on a single row. There's no way all fields could fit on a single row, especially when the browser is sized down. There could be far too many filter options. I think we'll probably use the filter options as 3 or 4 columns in most places, but the widget will probably be given the HTML source to set as filter options rather than generating any of it itself.
Tyson Phillips (Inactive)
added a comment - There's no way all fields could fit on a single row, especially when the browser is sized down. There could be far too many filter options. I think we'll probably use the filter options as 3 or 4 columns in most places, but the widget will probably be given the HTML source to set as filter options rather than generating any of it itself. I think for this we could add an additional widget button for the "filter" to appear, which you can set from the Widget. Additionally, a new method would be added to "setFilters($filters, $vars)" and that would allow you to pass in filter options and any vars to prepopulate the filters with.
The filters would ideally be a well-defined set of input fields. For example, modules currently use ModuleFields that are used to construct form fields. This could be used as-is, but it is called "ModuleFields" rather than something more generic like "InputFields". Perhaps the ModuleFields classes can be rewritten in a namespace under /core/ and that can be used instead for this purpose. It could also replace the ModuleFields used by modules, except that would be backward incompatible, thus the current behavior should be deprecated so it could be replaced in version 5.0.
In any case, the $filters passed to the Widget->setFilters($filters, $vars) could be an interface that represents the new core InputFields. This would contain a list of each inputField used to display the filters. This will allow the widget to define a consistent UI layout of all filter options (e.g. 3-column layout) rather than relying on each widget itself to provide that UI.
Tyson Phillips (Inactive)
added a comment - I think for this we could add an additional widget button for the "filter" to appear, which you can set from the Widget. Additionally, a new method would be added to "setFilters($filters, $vars)" and that would allow you to pass in filter options and any vars to prepopulate the filters with.
The filters would ideally be a well-defined set of input fields. For example, modules currently use ModuleFields that are used to construct form fields. This could be used as-is, but it is called "ModuleFields" rather than something more generic like "InputFields". Perhaps the ModuleFields classes can be rewritten in a namespace under /core/ and that can be used instead for this purpose. It could also replace the ModuleFields used by modules, except that would be backward incompatible, thus the current behavior should be deprecated so it could be replaced in version 5.0.
In any case, the $filters passed to the Widget->setFilters($filters, $vars) could be an interface that represents the new core InputFields. This would contain a list of each inputField used to display the filters. This will allow the widget to define a consistent UI layout of all filter options (e.g. 3-column layout) rather than relying on each widget itself to provide that UI. 
It seems like this has a dependency on the widget being updated to support this new filter toggle option