Show view sticky/readonly filters

[teosarca]

Type of issue

Feature request

Current behavior

Take following example:

• open a sales order, e.g. https://w101.metasfresh.com:8443/window/143/1003908
• go to Referenced documents and click on "Shipment Customer" for example, so a view which all related customer shipments is opened, e.g. https://w101.metasfresh.com:8443/window/169?refId=1003908&refType=143

Now, in this view, there is no way for the user to know from where she/he came from, why are just a few customer shipments, what she/he is seeing.

Expected behavior

Abstract

Internally, along with the regular filters (which user sees and which user can change) we also have "sticky filters".
The sticky filters are readonly filters (user cannot change them) which are attached to that view on view creation. That's done by the API automatically.
In the example above, the API attached a sticky filter to "Shipments" view which is filtering only those shipments which are referencing that Sales Order.

Approach suggestion

Backend:

• along with "filters" the API shall provide also a "stickyFilters" array (see http://w101.metasfresh.com:8081/swagger-ui.html#!/view-rest-controller/createViewUsingPOST and http://w101.metasfresh.com:8081/swagger-ui.html#!/view-rest-controller/getViewDataUsingGET ).
• a sticky filter is just like a filter but it won't have parameters (just filterId, caption and frequentUsed=true)

Frontend:

• shall render those stickFilters after the other regular filters, but on the same line.
• the stickyFilters buttons shall look like the other filter buttons but grayed out (not pressable).
• nice to have: the sticky filter button shall have an "X" icon. If user presses on it, the filter shall be taken out => TODO: we need an API for that.

It shall look something like in the picture below.
NOTE: the "order # 12345"it's actually the sticky filter's caption

wdyt?

[damianprzygodzki]

Low entry point. I've checked and the property that we differentiate filters on is frequent. In my opinion it will be okay to change it to type | filterType to tell frontend that filters is:
-frequent
-regular
-sticky (isnt better name static?)

[teosarca]

Shall be available on next rollout, e.g.

[teosarca]

Quick tested, using https://w101.metasfresh.com:8443/window/169?refId=1003908&refType=143
but it's not working...

[damianprzygodzki]

But, now i see, that you are sending only filters in data. But rendering is based on layout.

Try to send that in layout and it will be working - we can render empty filter without data, but not just data for active filter.

If you can't provide the static filter because you have no viewId, lets say that if for static filters is no data delivered, we will hide it.

[teosarca]

But we talked and agreed that it will be like this.
I cannot send you that in layout because the static/sticky filters are data related and not layout related.

Take a look here, #864 (comment)
API did not change after that.

---

Abstract: the use case where we want to use this is when we open referenced documents.
The layout is the same (and also there is no viewId when acquiring the layout),
but just the data is different. There we have that sticky/static filter which makes sure that only the referenced documents fetched.

[teosarca]

NOTE: also you are free to propose alternative solutions (even though it's a bit late in case of this task),
if those solutions are solving the core requirement.

[damianprzygodzki]

I think that ive proposed one already. Without layout, there can't be filters rendered.

If you can't provide the static filter because you have no viewId, lets say that if for static filters is no data delivered, we will hide it.

[teosarca]

If you can't provide the static filter because you have no viewId, lets say that if for static filters is no data delivered, we will hide it.

hmm, not sure if I understood it correctly... but if I got it right, i would say it's not possible because we really don't know that when we are generating the layout.
We even don't know the filterId or the filter's caption or how many sticky/static filters there are.
We know about those sticky filters only when we are really creating the view.

e.g. I am trying to open the Billing candidates (document references) from a given Sales Order.
The windowId and the layout of billing candidates is exactly the same when i am opening the "Billing candidates" from menu or when I am opening it from referenced documents.
And they shall be like that. The whole look and feel and functionalities shall be the same.

The difference between those 2 cases, "opening from menu)"and "opening from document references" is how we are creating the view data.
In "opening from menu" case we are allowing all sales orders.
In "opening from document references" we are enforcing a filter which says "allow only those which are referencing the sales order 1234567". That's a sticky filter. It's a filter which is always present and you cannot change it.

That sticky filter cannot be in layout simply because it's not about layouting. It's about data.
If it would be in the layout then the layout would be about filtering by "sales order 1234567" which is not correct.

More, we even cannot provide a list of available sticky filters in layout because it's not known. Those connections are auto-magically discovered by some core API which enables us to quickly introduce more documents even from different modules and let the API discover the connections between them.

To conclude, basically those are the reasons why the filter cannot be in the layout, from my point of view.

You might think to change the code in a way that accepts filters layout (as it is now) and also accept those sticky/static filters from data. Those sticky/static filters are pretty basic (e.g. no parameters, no need to send queries from them etc) and will stay like that. They are more like some labels which in future might have the option to delete it.

If you find it unacceptable, please propose a realistic solution which can be implemented on backend side too.

[damianprzygodzki]

Hardcoded solution integrated.

Warning! It corrupts filters model so it has to be refactored in future.

[metas-mk]

Tested.

Testcase window/143/1005665 (Order 2271)
a) Referenced Documents: Shipment Disposition. Jumps to Window window/500221?refId=1005665&refType=143 and sticky Filter "Order 2271" is set. OK

b) Press on Sticky Filter. Is deleted. All unfiltered data is shown. OK

Testcase /window/143/1005620
c) Referenced Documents: Shipment Disposition. Jumps to Window window /window/500221?refId=1005620&refType=143 and sticky Filter "Order 2271" is set. OK

Filter conflict issues appear but will be solved in other tasks as mentioned above.

Closing this Issue.