Make the parameter names visible in filters

[metas-rc]

Type of issue

• Feature request (enhancement)

Current behavior

• When a filter is opened, the longer names of parameters are nod completely displayed

Expected behavior

• The whole names should be seen.

Steps to reproduce

Please check the pic below:

[damianprzygodzki]

The filters have type secondary from the default, what means that the label and the input are sized with ratio 1:3.

We cannot allow to auto-size labels in secondary input due to layout assumptions.

Also we cannot fix the width of label to some length, because there is too much cases to fill them all.

What we can do here to display more is to provide from API type of widget like primary and then do not use fallback to secondary and achieve the 100% width label above the input. What it may cause is doubled height of filters dropdown.

[damianprzygodzki]

@metas-rc Do we have some new decision made here? Or can we close issue?

[teosarca]

Check with "primary" layout and it looks like this (see screenshot).

• for big filters, if u have to scroll, when trying to scroll the filter panel is closed => NOK
• the checkboxes does not look ok

@metas-mk wdyt?

[metas-mk]

Let' try to get rid of the most big filters. We already started in material receipt to only have specialty filters where most of parms are already set as constants. If we manage to do that, I believe that we can go the path of primary layout BUT not for flags (looks horrible). WDYT?

[damianprzygodzki]

Than please just change it on API side to secondary for flags. So it is no more frontend issue, can we close it?

[teosarca]

Hi @damianprzygodzki
I don't think so, because:

• the "type:primary|secondary" is considered for all filter parameters, and not for each one individually (see screenshot)
• more, personally, cannot imagine a place where a checkbox with type:primary which is actually layouted on 2 lines looks good => i think we might want to always layout the checkbox and label on same row.

[damianprzygodzki]

@teosarca so change the type property to be inside the parameters - it is resposible for single widget.

we cannot differentiate and display one widget different than others. We wanted to make generic widgets and thats the way they are working, property 'type' is defining their design. It relay on API side.

[damianprzygodzki]

I think that frontend gives you now full ability to manipulate widgets layout in filters, so i am adding integrated flag instead of mf turn.

[teosarca]

pls fix the checkboxes layout.

[damianprzygodzki]

It is fixed, also with buttons, labels and switches. Isnt it working?

[teosarca]

didn't check it... thought it wasn't since i didn't see any commits since last talked.

moving it to testing then...

[damianprzygodzki]

Thank you

[metas-lc]

IT
to test it after this task is ready: metasfresh/metasfresh-webui-api-legacy#334

[metas-lc]

IT
mainly it's fine, but the checkboxes are a bit too close and you can't see the whole text

we would need a distance ...something like you can see in sales order for example (window/143/1005135)

[damianprzygodzki]

We are back again in the beginning. That's my solution.

The filters have type secondary from the default, what means that the label and the input are sized with ratio 1:3.

We cannot allow to auto-size labels in secondary input due to layout assumptions.

Also we cannot fix the width of label to some length, because there is too much cases to fill them all.

Beside that, we have already implemented tooltip for labels, because the width of labels relay on width of your browser width.

The case which you provided:

we would need a distance ...something like you can see in sales order for example (window/143/1005135)

has the same behavior in filters and in window/143, but the point is that you have much more place for widget.

What i can propose is to add additional styling type (side by side 'primary' and 'secondary') to allow change this ratio, or align the checkbox to the right, to keep consistency for all of that widget type.

[cadavre]

Due to our auto-generator of UI, we always keep label to input proportion 1:3 in secondary type inputs (this means also always for checkbox, switch and button widgets). Filter window uses same UI generator as document window – the difference is document window is simply wider – it gives it more space for label. Solution might also be making filter container wider but it won't solve other cases with ellipsis for checkboxes (like users with lower screen resolutions).

@metas-lc keep in mind we cannot adjust widgets per window because we use one, single and unified UI generator – making change in one place makes the changes in all of them. Please propose your solution in this perspective (look at @damianprzygodzki proposal above).

[teosarca]

as discussed, the backend shall provide (layout) type:"different type" (TBD) .

[teosarca]

Update: introduced "primaryLongLabels" layout type.
Will be available on next rollout.

[metas-lc]

IT
text in filters are visible. Checkboxes are far enough and on the same line. OK
other filters which are not checkboxes, have the text on separate rows OK