Implement Zoom-into in webUI

[metas-mk]

Type of issue

Feature request

Current behavior

Currently there is no Zoom-into functionality in WebUI (that thing that in Swing can be used w/ right-mouse "Springe zu" and opens the window and record for the selected ID)

Expected behavior

Have that functionality or similar in WebUI.

Idea: In detail view have the labels then as links to zoom-into. let's solve that first, can think later about grid-view zoom-into.

belongs to metasfresh/metasfresh-webui-api-legacy#348

[teosarca]

How it shall work?

1. If a field supports ZoomInto backend provides "supportZoomInto:true" on layout field level.
   e.g.
   

2. To zoom into that field, you need to call one of the following endpoints

• field on header document: http://w101.metasfresh.com:8081/swagger-ui.html#!/window-rest-controller/getDocumentFieldZoomIntoUsingGET
• field on included document: http://w101.metasfresh.com:8081/swagger-ui.html#!/window-rest-controller/getDocumentFieldZoomIntoUsingGET_1

The endpoint will return something like:

Basically the result has 2 properties:

• "documentPath": which contains windowId, documentId of the the document which we need to open
• "windowLayout" : backend automatically prefetched the window layout of the window we are zooming into. It was prefetched just to avoid another backend call. Might be that we don't need this...

Important

• the "zoomInto" endpoint calls can fail for various reasons. On frontend side, please make sure you first call the endpoints and ONLY if success you start building the new window.

Why not providing the ZoomInfo on each field, when we fetch the document data?

The main reason is because we would need extra computation to figure out which is the actual windowId where we need to zoom.

[damianprzygodzki]

How do we want achieve a context menu over widgets? Most of them are editable inputs so the replacing native context menu would be limiting default functionalities. @cadavre We need your help here.

[cadavre]

I think going into context menu "Zoom in" is not a good follow-up of Swing's client. ;)

This is how I see we can do it:
If supportZoomInto:true – show additional perpendicular (vertical) icon-button next to (on right) of the widget. If now only single option is available ("zoom in") – let this icon-button instantly "zoom into" document selected in widget; if - in the future - there would be more options than just one – we can make icon-button with three dots which will open dropdown with more options.

and

As an addition to above I would like to add something like [ctrl]+click widget to "zoom in". Possible @damianprzygodzki ?

[damianprzygodzki]

@cadavre yes, it is possible. But i am thinking - you should be focused inside widget then, shouldnt we be consistent and proceed like with devices section (tab navigation)?

[cadavre]

I guess it should be possible even without focus. Imagine when someone is browsing document – already filled and want to go to Business Partner to check other documents. Simple go with mouse over widget and click to open. Also remember about case with widget read-only – cannot be focused, but still we want to have possibility to zoom-in.

[damianprzygodzki]

Yes, sorry, you are right. We can proceed this way.

[teosarca]

Hi guys,

Have you also considered?

Idea: In detail view have the labels then as links to zoom-into. let's solve that first, can think later about grid-view zoom-into.

I am really not sure if that's a good idea, but i would really want to have your input.

[cadavre]

Labels are also not a bad idea. What I would do is add some small "go into record" icon next to label that is enabled to "zoom in". Wdyt?

[teosarca]

or in case the widget supports zoomInto, we could render the label as a browser link.

To be honest i am really not sure and I think we would not be able to decide now.
My suggestion is to render it as you think it would look good and which approach is the fastest one and we can evolve from there.
wdyt?

[cadavre]

I would not really change label style to link. But afaik I think approach with labels would be fastest. @damianprzygodzki ?

[damianprzygodzki]

@cadavre

show additional perpendicular (vertical) icon-button next to (on right) of the widget.

And what is the difference between labels and icon-button? I think in both cases it is the same as Devices button.

[cadavre]

Both ideas on screenshot here.

[damianprzygodzki]

Both ideas are ok, but i would go with icon-button to avoid problems with labels on small resolutions.

[teosarca]

as discussed, let's go with the label approach.

• same style as a regular label (same size, font, color)
• when hovering, it shall be underlined, like standard web links

The document shall be opened in a new browser tab.

[damianprzygodzki]

@teosarca We need just document path (windowId, documentId). Could we just provide in layout (or we should use data for it, like with newRecordWindowId properties in Lookup):

supportZoomInto: {
   windowId: 143,
   documentId: 100000
}

And bam. Thats it. No additional calls. Because my concern is that after click on label, we can experience a lag before actual redirect because before opening new tab we have to wait for your response. It would be great to avoid that.

The additional windowLayout are just useless bytes, because we init app in new browser tab.

[teosarca]

@damianprzygodzki

Why not providing the ZoomInfo on each field, when we fetch the document data?
The main reason is because we would need extra computation to figure out which is the actual windowId where we need to zoom.

Basically we cannot provide the windowId because it needs computation.
We cannot provide the documentId in layout because the documentId shall be fetch from field value.
The layout is not aware of what data it's inside, it's just static.

[metasnw]

testing on w101:

zoom from sales order to price syste breaks bread crumb navigation:

found out its jumping to the wrong window

@teosarca how do I configure which window he zooms to ?

basically you don't..... or to put it in other words, the windowId is detected same as in swing
(with some exceptions)
in this specific case, the simple way to fix it is to open Table&Columns, select M_PricingSystem table and change the AD_Window_ID

afai see we have to configure the zoom targets to windows that are part of the menu.

tested:

• OK: jump from generic window single view like sales order to e.g. bpartner
• OK: jump from modal window like edit contact to e.g. greeting
• OK: switch language and then jump

todo testcase:
jump to a window where I do not have permission

[metasnw]

http://docs.metasfresh.org/webui_collection/EN/Jumpto.html

[teosarca]

Quick tested

• selected a manufacturing order: https://w101.metasfresh.com:8443/window/53009/1000001
• click on "Priority" label
• backend throws an exception but frontend shows no error => it shall display the error

[metas-lc]

IT

1. zoom in to a window where the role doesn't have permission:

• go to Print Format window (240), press on advanced edit
• zoom into Jasper Process
  => empty window opens(404 Document not found) with error: no window read permission OK

2. Priority label in Manufacturing

• go to Manufactuing Order and try to zoom in to Priority
  => you can't. There is no zoom in on that field OK

3. zoom into price system

• go to sales order and zoom into price system
  => window 146 opens OK??
  https://w101.metasfresh.com:8443/window/146/2000837
  shouldn't this window open? https://w101.metasfresh.com:8443/window/540320/2000837

4. try to zoom in to a window when the value is null

• go to sales order, advanced edit and zoom into Activity
  => no window opens. error: Cannot fetch ZoomInto infos from a null value OK?

checked several zoom into, from both document view and advance edit and they work fine

[metas-mk]

@metas-lc hi lili. No. 4 is OK. For No. 3. Can u please create a follow up task. thx.

[metas-lc]

@metas-mk Thank you. Created task for No. 3 metasfresh/metasfresh#1620