New widget for date filtering

[metas-mk]

Is this a bug or feature request?

Feature Request

What is the current behavior?

Currently, when the user wants to browse through dates, then the current date-range filter must be used.
In some cases this is not handy at all... to many clicks.

What is the expected or desired behavior?

Take following example: https://w101.metasfresh.com:8443/window/540253

Remark:

• the filter is "frequent:true" (so it will be displayed directly on view page and not inside the Filters button dropdown)
• the filter has only one parameter
• the parameter has set "showIncrementDecrementButtons:true"
• the parameter has set "widgetType:Date" or "widgetType:DateTime"

=> Those are the conditions to identify that we are dealing with a different filtering widget.

In this case, the frontend shall:

• the caption shall display the current date instead of "Filters: Date", so the user knows on which date he/she is filtering
• render the "<" and ">" which will decrement/increment the current date with 1 day. When user is pressing one of the buttons, the frontend shall:
  ** automatically decrement/increment the date and apply the filter
  ** update the caption

Please let me know what do you think.
I am also open to suggestions to change the protocol as long as we deliver the functionality described here.

[metas-mk]

Needs:
metasfresh/metasfresh-webui-api-legacy#705

[ottosichert]

I implemented the date stepper for date ranges as well, because their widgetType is Date as well.

Currently clicking on < or > will move the date range by one day, do you want to keep this behaviour or alternatively move the date range by its own length, i.e.:

Previous date range: 25.11.2017 - 01.12.2017
Next date range: 09.12.2017 - 15.12.2017

[metas-mk]

moin @ottosichert
merged, rollout and quick test.
here a first feedback about it
a) press on filter button and parm for date --> calendar opens in weird, small dropdown instead of showing the caledar as usual
b) the increment/ decrement button dont' seem to have the same height as the filter button itself (a pixel or 2 too small)

[ottosichert]

Hi @metas-mk,

a) This issue is separate from this feature and existed before my PR (at af74af7). I will look into it
b) It's actually half a pixel on Firefox (not visible) and one pixel on chrome (visible). I will fix it as well

[metas-mk]

Thx.
@ottosichert found another one. also just cosmetic. seems as if the gap between 2 filter buttons are now too narrow when w/o decrement/increment buttons.

[ottosichert]

This issue was introduced by my feature PR, resolving it as well

[metas-lc]

IT

1. i had to make some configs to test this task:
   (i might need to create a task to have them by default)
   went to table window for qtyonhand, column Date => set range filter on N, filter +/- buttons on Y and Filter default Value on NOW
2. opened window /540253
   => there are 2 arrows - height is OK, as big as the filter
3. press on date filter
   => there is no scroll, the date panel fits
   => question: i wonder if we shall move the calendar a bit more to the right, right under the date? And to change the way date appears "2017-12-05T00:00:00.000+01:00"? (i have to ask)
4. press on filter, open calendar, don't change the date, press apply
   => error: undefined has an invalid date. (don't know if it's task related?)
5. press on < and > arrows
   => date changes accordingly OK
6. navigating back:
   i went from Stock Control Purchase window (540253) to sales order (143)
   pressed on date filter in sales order => notice a range date filter
   directly pressed on back => notice the filter is still shown, name changed, but it's still a range date filter NOK (probably not task related)

picture for steps 3 and 4

picture for step 6

[metas-lc]

Found another problem while testing metasfresh/metasfresh#3275
go to e.g. Purchase order (window/181), select default filter: Date Promised
add a date, set an hour, apply
select the filter again => the date and hour is reset. Shall keep the latest changes

[wiadev]

@teosarca While I'm working n this task, I figured that we have a timezone issue on both of front-end and back-end.

So I've updated the front-end to send timezone to back-end but back-end can't parse it.

Check out the following screenshot, please.

[metas-lc]

IT
3. the calendar appears like a tooltip (looks fine for me) and it's right under date OK
4. new error appears NOK

"Failed converting DateDoc's value '2018-01-19T01:00:00+02:00' (class java.lang.String) to class java.util.Date↵ LookupDataSource: null↵ Widget type: Date"

Actually the filter seems to not work anymore because of that error
5. not working because of no.4 NOK
EDIT: for 4 and 5 created task metasfresh/metasfresh-webui-api-legacy#796

6. could not reproduce OK

.
about the other problem in purchase order - date promised => the problem was solved, the filter remembers the date you set BUT i found a weird issue, similar with old step 4
purchase order -> filter -> default -> date promised -> set a date -> important: click in the field of the date (somewhere in the middle of 2018-01-22T00:00:00.000+02:00)
=>
undefined has an invalid date. NOK

[wiadev]

@metas-lc
Regarding 4 and 5, I've already described in #1387 (comment).

@teosarca Can you take a look at it, please?

[metas-lc]

@wiadev ah yes sry. I didn't see it. I'll create a task for it.

[metas-lc]

metasfresh/metasfresh-webui-api-legacy#796

[teosarca]

@wiadev @metas-lc that's not a backend issue.
The problem is the frontend is no longer respecting the date format.

In console i've found:

Caused by: org.adempiere.exceptions.AdempiereException: Failed converting '2018-01-16T00:00:00+02:00' to date.
 Please use following format: yyyy-MM-dd'T'HH:mm:ss.SSSXXX.
 e.g. 2018-01-20T01:17:34.991+02:00

So basically, you are no longer including the milliseconds.

[siemiatj]

@teosarca can we close this one ? Seems to be really old and doesn't look like it's relevant anymore.

[teosarca]

yup, closing.