included view: blurWhenOpen support

[teosarca]

Is this a bug or feature request?

FR

What is the current behavior?

In a view, you click on a row so the included view is opened on the right side panel.
While the included view (on the right) is open the main view (left side) is blurred out.
If you try to click on the actions button of the main view (left side) you just close the included view instead of running the action.

Which are the steps to reproduce?

• open Picking Tray: https://w101.metasfresh.com:8443/window/540206
• select a row => the included view is opened
• try to click on the left side actions button (it shall have "Take out HU" label).

What is the expected or desired behavior?

1. Refactoring: viewLayout response

We deprectated supportIncludedView and supportIncludedViewOnSelect properties.
Please don't use them because we plan to remove them.

Instead "includedView" (map) property was introduced, which can contain following properties:

• openOnSelect: true/false => shall do the same as supportIncludedViewOnSelect
• blurWhenOpen: true/false => the new property which is the subject of this task (see below)

So, the substitutes of the old properties are:

• supportIncludedView => true if the "includedView" property is present
• supportIncludedViewOnSelect => "includedView" -> "openOnSelect"

2. Support "includedView" -> "blurWhenOpen" property

If true, it shall behave EXACTLY how it is now.

If false:

• the main view (left side) shall not be blurred out
• the action button/dropdown shall be clickable, so i would be able to run an action without closing the right side view.

required for metasfresh/metasfresh#518

[ottosichert]

There is another issue first:

If there is no selection, quick actions are shown. => OK
If there an entry is selected, the included view is opened => OK but the quick actions of the main view disappear => NOK

[ottosichert]

EDIT: @metas-mk advised me there will only be actions for entries with a given handling unit, so this comment is obsolete

EDIT 2: @metas-mk confirmed there is an issue with Picking Tray, @teosarca will see about this

---

I further investigated this issue and could narrow it down to no actions passed for given windowType, viewId and entry id:

When an entry is selected (in https://w101.metasfresh.com:8443/window/540206), the QuickActions component requests actions from the API with current windowType and viewId and stores them in its state. The result (e.g. to http://w101.metasfresh.com:8081/rest/api/documentView/540206/540206-c37eb8e86b464da3b7f8cb3767bc5879/quickActions?selectedIds=1000124) for all entries in this exact table is each

{"actions":[]}

Interestingly when multiple items are selected (e.g. http://w101.metasfresh.com:8081/rest/api/documentView/540206/540206-c37eb8e86b464da3b7f8cb3767bc5879/quickActions?selectedIds=1000104,1000103) this response is yielded:

{"actions":[{"processId":"ADP_540874","caption":"Take out HU","description":"","quickAction":true,"defaultQuickAction":false,"disabled":true,"disabledReason":"Nur eine Zeile soll ausgewählt sein"}]}

@teosarca Do you know if there was an API change in the last two days regarding the Picking Tray?

[teosarca]

EDIT 2: @metas-mk confirmed there is an issue with Picking Tray, @teosarca will see about this

Yes, basically i cannot add an HU to picking slot if #1258 is not fixed.

[ottosichert]

1. Refactoring: viewLayout response

We deprectated supportIncludedView and supportIncludedViewOnSelect properties.
Please don't use them because we plan to remove them.

Instead "includedView" (map) property was introduced, which can contain following properties:

• openOnSelect: true/false => shall do the same as supportIncludedViewOnSelect
• blurWhenOpen: true/false => the new property which is the subject of this task (see below)

So, the substitutes of the old properties are:

• supportIncludedView => true if the "includedView" property is present
• supportIncludedViewOnSelect => "includedView" -> "openOnSelect"

@teosarca Does this also apply to row data? It currently looks like this:

[
  {
    "...": "...",

    "includedView": {
      "viewId": "afterPickingHUs-4e881f59082a4a28a17a4ab3db2a5a7f",
      "windowId": "afterPickingHUs"
    },
    "supportAttributes": false,
    "supportIncludedViews": true
  },
  { "...": "..." }
]

[teosarca]

@ottosichert nop, i did the change only on layout level.

[ottosichert]

Okay thanks for the info. Will it be changed anytime soon?

[teosarca]

not planned.

[teosarca]

only if is needed or if u have an improvement suggestion....

[ottosichert]

It's not needed and I don't necessarily see an improvement here (maybe besides consistency). I would have added a fallback in my coming PR if it was planned.

[teosarca]

@ottosichert lili created some data for you: https://w101.metasfresh.com:8443/window/540371

[ottosichert]

Thansk for the data. Clicking on Take out HU will not close the included view and execute the quick action.

After clicking the quick action the view flashed but nothing changed. When refreshing the page, the entries are gone. Is this supposed to work like that?

Furthermore the selection seems buggy, when selecting the item as in your screen shot everything works fine (one item selected, quick action enabled). When selecting the item below, both TU and CU are selected. Is this correct?

[metas-lc]

IT

1. open Picking Tray Clearing (Prototype) (540371)
2. select a slot that has picked and processed HUs
   => right view opens OK
   => left view is still visible (not blurred) OK
3. on the left side, select the HU
   => take out HU button appeared OK
4. select something on right side
   => take out HU button is still there OK
5. press on "take out HU" button
   => the selected Hu goes on the right side OK
   => both sides are independent OK

=> you have to select the "Picking Tray Clearing (Prototype)" breadcrumb to see the HUs from the right side (created backend task: metasfresh/metasfresh-webui-api-legacy#643)

!!! @ottosichert Question: when you navigate on slots (left side), the right side is not refreshed . (e.g. there is no afterPickingHUs). Is it wanted? (for me it's ok, but just to make sure)

[ottosichert]

@metas-lc Thanks for your feedback and sorry for my late response.

I can see the right side is not refreshed after the selection on the left side changes:

• Open Picking Tray Clearing (Prototype) (windowType 540371)

• Window fetches data from http://w101.metasfresh.com:8081/rest/api/documentView/540371/540371-439d70cb96de466fb1b0bc7274b6c8e7?firstRow=0&pageLength=20

  See JSON response

  {
   "windowId": "540371",
   "viewId": "540371-439d70cb96de466fb1b0bc7274b6c8e7",
   "size": 18,
   "result": [
     {
       "id": "1000104",
       "fieldsByName": {
         "ID": {
           "field": "ID",
           "value": "1000104",
           "widgetType": "Integer"
         }
       },
       "type": "M_Picking_Slot",
       "supportAttributes": false,
       "supportIncludedViews": true,
       "includedView": {
         "windowId": "afterPickingHUs",
         "viewId": "afterPickingHUs-439d70cb96de466fb1b0bc7274b6c8e7"
       },
       "colspan": true,
       "caption": "101.0  "
     },
     {
       "id": "1000103",
       "fieldsByName": {
         "ID": {
           "field": "ID",
           "value": "1000103",
           "widgetType": "Integer"
         }
       },
       "type": "M_Picking_Slot",
       "supportAttributes": false,
       "supportIncludedViews": true,
       "includedView": {
         "windowId": "afterPickingHUs",
         "viewId": "afterPickingHUs-439d70cb96de466fb1b0bc7274b6c8e7"
       },
       "colspan": true,
       "caption": "102.0  "
     },
     "[...]"
   ],
   "firstRow": 0,
   "pageLength": 20,
   "type": "540371"
  }

• All items on the left side have the same includedView:

  {
    "windowId": "afterPickingHUs",
    "viewId": "afterPickingHUs-439d70cb96de466fb1b0bc7274b6c8e7"
  }

• Thus changing the selection on the left side does not refresh the right side as it's the same view!

@teosarca Do you know if this is wanted?

[teosarca]

@ottosichert in case it's exactly the same view it's OK to not be queried again.
But in case the viewId is different the frontend shall query it.

[ottosichert]

@teosarca okay that makes sense.

Is it intended that in this case all items on the left side have the exact same includedView?

Besides that, by manually altering the includedView of some items I found out the view does not query again, I will resolve this now.

[teosarca]

Is it intended that in this case all items on the left side have the exact same includedView?

Generally speaking, no.
But for our particular case, the Picking Tray Clearning window, yes we want to have the same includedViewId.

Reason behind: when we initially developed this included view feature, we started with cases where the "included view" really depends on what row you select on main view.
But in case of Picking Tray Clearing that does not apply because there we want to have side by side views. So we decided to return same viewId for any row you select, just to have that effect.

Besides that, by manually altering the includedView of some items I found out the view does not query again, I will resolve this now.

thanks!

[metas-dh]

Results of IT2
tested in mf15

• repeated testcase of IT1: working fine, OK (remaining problem in back end task also OK now)
• changing the selection on the left side does not refresh the right side as it's the same view:
  =>if it is the exact same includedViewID as is true in Picking Tray Clearing (Prototype): OK
• changing the selection on the left side does refresh the right side if it's not the same view:
  => if includedViewID is different (e.g. in Picking Terminal), then view queries again: OK