[MGNLUI-7669] Support column filter for nodes using configurable node filter property name Created: 06/Dec/22  Updated: 09/May/23

Status: Open
Project: Magnolia UI
Component/s: None
Affects Version/s: 6.2.26
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Viet Nguyen Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-5903 Column Filter: Improve the JCR data p... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLUI-7670 Implementation Sub-task To Do  
MGNLUI-7671 Review Sub-task To Do  
MGNLUI-7672 Pre-Integration QA Sub-task To Do  
MGNLUI-7673 QA Sub-task To Do  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Nucleus Quality Maintenance
Team: Nucleus

 Description   

Currently we supported column filter for properties but not node and sub-node level. For node, only filter by node identifier which does not make sense (MGNLUI-5903).
This cause some difficulties when customers using filter with nodes.

The improvement concentrate on supporting easy of use and flexibility of configuration in that:

  • Allow customer to configure filter property name for nodes. In case the filter works on properties, the filter property name should be ignore or directly use the filtering property as the filter property name (which allow consistency in implementation).
  • Development notes:
    • From this pull request we can see that we should take the configured filter property name to get the value to filter instead of use the node identifier.
    • Also in case the filter property name does not exist, do not stop the processing flow. Use a lowest priority value for it instead with a warning or info in the log.
    • We may not support sub-nodes filtering to reduce the usage complexity and implementation efforts. With a note that we are trying to simplify the product to help customers easier to adopt and use it rather than supporting a lot of complexity functions. Customers who want to have more specific functions should extends our implementation or request our Professional services for doing that.


 Comments   
Comment by Vincent Faidherbe [ 06/Dec/22 ]

We need this capability for one of our projects. That being said, we agree with the last note: if it isn't supported out of the box, it should be at least possible through extensibility.

Generated at Mon Feb 12 09:48:15 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.