0023433: Date autocomplete does not fully work with date format MM-DD-YYYY

Notes
(0057710) AugustoMauch (administrator) 2013-04-03 17:52	Hi Paolo, I am not sure this is an issue. The description says that with the format DD-MM-YYYY if you enter two digits the systems assumes it is the day of the current month, and that if you do the same with the format MM-DD-YYYY, it assumes that the first two digits represent the first component of the date, which in this case is the month and not the day. Stated that way it might look like an issue, but consider this other approach: If the user enters one or two digits, they will represent the first component of the date (the day in the DD-MM-YYYY format, the month in the MM-DD-YYYY format). The other two components will be automatically filled. If the user enters three or four digits, the first two ones will represent the first component, and the remaining ones will represent the second component. The third component will be automatically filled. This is the way the auto completion of dates was designed and I think it is working properly. We could consider changing it and using your approach, but I do not think it is a good idea, because probably lots of people are used to the way the autocompletion works currently. In any case, we would have to treat it as a design defect, because right now it is working the way it was designed.

(0057737) pjuvara (viewer) 2013-04-05 11:43	Hi Augusto, let me put aside the topic of whether this is a defect, a design defect or a feature request. That is certainly for you and the Openbravo team to decide. I would like to stress that this is indeed an issue. When the feature was specified (and I was involved in driving the specification), it was clearly stated that the intended behavior of the feature was to minimize the effort of entering a date field making smart assumption about the defaulting. In particular, if two digits are entered they should be assumed to be day of the current month. The design of the feature clearly made the incorrect assumption that the day of the month would always be the first component of the date. That could be considered a bug or a design defect but it is nonetheless an issue. With regards of changing the behavior and its impact on existing users, quite frankly I would not worry about it. For users operating the system under MM-DD-YYYY format, the current behavior is completely useless and exclusively a source of annoyance. I really cannot imagine any use case where somebody would want to default the date they way the system does. Thanks Paolo

(0057738) AugustoMauch (administrator) 2013-04-05 11:51	Thanks Paolo, Now it is clear that it is indeed an issue, and a defect, to be specific, because it is not working according to its design. Thanks for clearing that up. With regards, Augusto

(0057783) AugustoMauch (administrator) 2013-04-08 16:30	Hi Paolo, I have been thinking about how the date autocomplete should work with the MM-DD-YYYY format and I can't find any not confusing approach. Suppose today is 8th April 2013 (04-08-2013). Let's see what should happen in the following scenarios: Text entered by user Autocompleted Date 08 04-08-2013 0805 05-08-2013 08-05 05-08-2013 08052013 05-08-2013 08-05-2013 05-08-2013 For me, it doesn't make any sense that if the user enters 08-05-2013, the resulting date is 05-08-2013. I think it is also confusing that entering 08-05 results in 05-08-2013. For me it only makes sense to use the autocompletion when only one or two digits (days) are entered. I asked Rob what should be the proper behaviour and he thinks that the autocompletion of dates should be disabled if a format other than DD-MM-YYYY is used, because in those cases we are not able to provide a date auto completion that is not confusing. Can you think of any approach that works for both date formats and that is not confusing? With regards, Augusto

(0057786) plujan (viewer) 2013-04-08 17:33	Augusto, probably you should take a look at Excel/OpenOffice/LibreOffice date management, since they also do this "smart" autocomplete.

(0057788) AugustoMauch (administrator) 2013-04-08 18:13	Libreoffice does it like this: If a number is entered (i.e. 04, 0508, etc), that number represents the number of days passed since 1/1/1900. If the date separator is used: 12/05 -> 12/05/2013. The years is autocompleted, the number before the date separator represents the month number and the number after the date separator represents the day number.

(0057885) hgbot (developer) 2013-04-15 11:16	Repository: erp/devel/pi Changeset: 9e3e972eb6d86a6e787cdee5cf242d803e988694 Author: Augusto Mauch <augusto.mauch <at> openbravo.com> Date: Mon Apr 15 11:15:53 2013 +0200 URL: http://code.openbravo.com/erp/devel/pi/rev/9e3e972eb6d86a6e787cdee5cf242d803e988694 [^] Fixes issue 23433: Modified date autocompletion to support MM-DD-YYYY format The date autocompletion has been modified. Before this fix, If only one or two digits were entered, they represented the first date part of the format (number of days in DD-MM-YYYY format, number of months in MM-DD-YYYY format). Now, if only one or two digits are entered they will represent the number of days, regardless of the date format being used. The rest of the date parts will be autocompleted as usual, using the current month and year. --- M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-date.js ---

(0057886) AugustoMauch (administrator) 2013-04-15 11:19	Test plan: - Check that with the DD-MM-YYYY format the date autocompletoin works as usual. - Change the date format in Openbravo.properties to MM-DD-YYYY and check that if only one or two digits are entered, they represent the number of days (i.e. 08 is autucompleted to 04-08-2013). If more digits are entered, then the autocompletion will work as usual (i.e. entering 0408 results in 04-08-2013).

(0057972) hudsonbot (viewer) 2013-04-16 19:18	A changeset related to this issue has been promoted main and to the Central Repository, after passing a series of tests. Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/8df08bea850d [^] Maturity status: Test

(0058080) shankarb (viewer) 2013-04-22 10:21	Code reviewed and tested in pi changeset 6f099465923b

Issue History
Date Modified	Username	Field	Change
2013-03-30 19:55	pjuvara	New Issue
2013-03-30 19:55	pjuvara	Assigned To	=> dbaz
2013-03-30 19:55	pjuvara	Modules	=> Core
2013-03-30 19:55	pjuvara	Triggers an Emergency Pack	=> No
2013-03-30 23:39	dbaz	Assigned To	dbaz => AugustoMauch
2013-04-03 17:52	AugustoMauch	Note Added: 0057710
2013-04-03 17:52	AugustoMauch	Status	new => feedback
2013-04-05 11:43	pjuvara	Note Added: 0057737
2013-04-05 11:51	AugustoMauch	Note Added: 0057738
2013-04-05 11:51	AugustoMauch	Status	feedback => new
2013-04-08 16:30	AugustoMauch	Note Added: 0057783
2013-04-08 16:30	AugustoMauch	Status	new => feedback
2013-04-08 17:33	plujan	Note Added: 0057786
2013-04-08 18:13	AugustoMauch	Note Added: 0057788
2013-04-15 11:10	AugustoMauch	Issue Monitored: shankarb
2013-04-15 11:10	AugustoMauch	Review Assigned To	=> shankarb
2013-04-15 11:10	AugustoMauch	OBNetwork customer	=> No
2013-04-15 11:10	AugustoMauch	Status	feedback => new
2013-04-15 11:16	hgbot	Checkin
2013-04-15 11:16	hgbot	Note Added: 0057885
2013-04-15 11:16	hgbot	Status	new => resolved
2013-04-15 11:16	hgbot	Resolution	open => fixed
2013-04-15 11:16	hgbot	Fixed in SCM revision	=> http://code.openbravo.com/erp/devel/pi/rev/9e3e972eb6d86a6e787cdee5cf242d803e988694 [^]
2013-04-15 11:19	AugustoMauch	Note Added: 0057886
2013-04-16 19:18	hudsonbot	Checkin
2013-04-16 19:18	hudsonbot	Note Added: 0057972
2013-04-22 10:21	shankarb	Note Added: 0058080
2013-04-22 10:21	shankarb	Status	resolved => closed
2013-04-22 10:21	shankarb	Fixed in Version	=> 3.0MP23

Relationships [ Relation Graph ] [ Dependency Graph ]