RelativeDateItem with 9 million months ago

[matus_b]

Hi Isomorphic,

Our QAs discovered issue in the relativeDateItem. When the item is in relative mode and the quantity field contains huge number it is possible to experience two kinds of issues:

1. DSRequest will contain advanced criteria where the value of the field is 0NaN-NaN-NaNTNaN:NaN:NaN.
2. DSRequest will contain advanced criteria where the value of the field is the last valid value.

On the showcase I was able to reproduce second issue:
First the quantity is 900000 months. The date is still valid and shown with negative year.
If we increase quantity to 9000000 months, attached formatter will be invoked with standard base time (1970), but the value of the field will be reported as last valid value which was set to the item.



I can understand that there will be some limitations for the dates, but I would like to know how you suggest to prevent user from producing such wrong values.

I already consider setting start and end date, but this limits only the datePicker component.
Also I tried to use DateRangeValidator. But because the item is reporting the last valid value only, it is possible that I will set 9 millions months ago, but the validated value will be 1 month ago and validator will not complain.

Thanks
Matus


Reproduced on SmartClient Version: v10.0p_2016-09-27/LGPL Development Only (built 2016-09-27) with GC45.
Modified showcase source code in the attachments.

[matus_b]

Hi, did you have chance to look into it? Please let me know if you are aware of this post.

[Isomorphic]

Apologies for the delay in getting back to you - we're running some tests and will update here shortly today.

[Isomorphic]

We've added code to deal with this issue - which is caused by the limitations of the javascript Date object - the fix results in the "quantity" field in RelativeDateItems being limited to 999999, so you won't be able to enter a number greater than that.

It seems like it would always be inappropriate for a user to request a date range of hundreds of thousands of months anyway - but you can now deal with such details in your validator, since it should always return a valid, supported date.

[matus_b]

Hi, I noticed that 5.1p already got nightly build from 15.11. but not 5.0p which we are currently using. Can you please check if 5.0 branch was fixed as well?
edit: PowerEdition

[matus_b]

We are still waiting for the fix. Please can you answer previous question?

[Isomorphic]

Apologies for the delay - the fix was made at the time we noted, but there's been a problem with the nightly build for your branch - we're looking into it and will let you know when it's resolved and a build is available.

[Isomorphic]

The build problem on the SmartGWT 5.0 / SmartClient 10.0 branch has been fixed - there's a new build on the builds page..

[matus_b]

Hi Isomorphic,

even your fix helped us to move forward, we are still not able to make the RelativeDateItem work flawlessly.
Please, let us know when you will start looking into it.

Issue 1
1. select N months ago, default quantity value is 1
2. set quantity field value to 123456789
3. click log value = Value is Sat Oct 29 00:00:00 GMT+200 2016
expected: value should be the min possible date
Value is Wed Aug 29 00:00:00 GMT+200 -81317
4. quantity field value is reset to 1
expected: quantity field value should be set to max possible value (I assume it is 999999)


Issue 2
We want to allow to type in quantity field only numbers. For this purpose we set following:

SpinnerItem quantityFieldProperties = new SpinnerItem();
quantityFieldProperties.setKeyPressFilter("[0-9]*");
relativeDateItem.setAutoChildProperties("quantityField", quantityFieldProperties);

(source code attached)

1. select N months ago, default quantity value is 1
2. click log value = Value is Sat Oct 29 00:00:00 GMT+200 2016
3. set quantity field value to 2
4. click log value = Value is Sat Oct 29 00:00:00 GMT+200 2016
expected: Thu Sep 29 00:00:00 GMT+200 2016
5. click spinnerItem icon to set value to 3
6. click log value = Value is Mon Aug 29 00:00:00 GMT+200 2016
this is right


Note:
After setting custom quantityFieldProperties Issue 1 is gone.
It allows to type 123456, when we type one more additional number, value gets automatically reseted to 999999.


Reproduced on
SmartClient Version: v10.0p_2016-11-29/LGPL Development Only (built 2016-11-29)
GC45

[Isomorphic]

In your current build, pressing the Enter key is how the quantity field propagates it's new value when a user changes it by typing - just clicking out of the quantityField (onto your log button) was not updating the RelativeDateItem's value.

We've made a change to address that in builds dated December 1 and later - the value will now be correctly updated on blur() of the quantityField, and your entered values will now be correctly capped at RelativeDateItem.maxQuantity - 999999 by default - as the user types. In your sample code, such large quantities will fail validation anyway, since you've set a recent startDate.