-
Notifications
You must be signed in to change notification settings - Fork 34
Show view sticky/readonly filters #864
Comments
Low entry point. I've checked and the property that we differentiate filters on is |
Quick tested, using https://w101.metasfresh.com:8443/window/169?refId=1003908&refType=143 |
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. |
But we talked and agreed that it will be like this. Take a look here, #864 (comment) Abstract: the use case where we want to use this is when we open referenced documents. |
NOTE: also you are free to propose alternative solutions (even though it's a bit late in case of this task), |
I think that ive proposed one already. Without layout, there can't be filters rendered.
|
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. e.g. I am trying to open the Billing candidates (document references) from a given Sales Order. The difference between those 2 cases, "opening from menu)"and "opening from document references" is how we are creating the view data. That sticky filter cannot be in layout simply because it's not about layouting. It's about data. 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. |
[#474](metasfresh/metasfresh-webui-api-legacy#474) Dashboard API: specify position when adding a new KPI/target indicator [metasfresh/metasfresh/issues#1814](#1814) Hide Processed flag from all M_InOut/Returns windows (webui) [#926](metasfresh/metasfresh-webui-frontend-legacy#926) Board window does not open via Sitemap menu [#470](metasfresh/metasfresh-webui-api-legacy#470) Cache image endpoint [#464](metasfresh/metasfresh-webui-api-legacy#464) Dashboard API: unify get available kpis/targetIndicators endpoints [#465](metasfresh/metasfresh-webui-api-legacy#465) Provide Endpoint w/ entry selections for given Breadcrumb [#864](metasfresh/metasfresh-webui-frontend-legacy#864) Show view sticky/readonly filters [#833](metasfresh/metasfresh-webui-frontend-legacy#833) Dashboard Window w/ Swimlane type functionalities [#1861](#1861) Performance degradation in HUKey.isReadonly() [#1873](#1873) Fix control amount and qty in payment data imported from camt.54 [#467](metasfresh/metasfresh-webui-api-legacy#467) board API: GET board/{boardId}/card?cardIds [#913](metasfresh/metasfresh-webui-frontend-legacy#913) Incompatible Sock.js versions me-45
Hardcoded solution integrated. Warning! It corrupts filters model so it has to be refactored in future. |
Tested. Testcase window/143/1005665 (Order 2271) b) Press on Sticky Filter. Is deleted. All unfiltered data is shown. OK Testcase /window/143/1005620 Filter conflict issues appear but will be solved in other tasks as mentioned above. Closing this Issue. |
Type of issue
Feature request
Current behavior
Take following example:
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:
Frontend:
It shall look something like in the picture below.
NOTE: the "order # 12345"it's actually the sticky filter's caption
wdyt?
The text was updated successfully, but these errors were encountered: