Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0023433
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] B. User interfaceminoralways2013-03-30 19:552013-04-22 10:21
ReporterpjuvaraView Statuspublic 
Assigned ToAugustoMauch 
PrioritynormalResolutionfixedFixed in Version3.0MP23
StatusclosedFix in branchFixed in SCM revision9e3e972eb6d8
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toshankarb
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

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

DescriptionWhen date format is DD-MM-YYYY, the date fields autocomplete correctly.
- If you enter a single number, it assumes it is the day of the current month (example 15 becomes 15-03-2013)
- If you enter two numbers (with or without separator), it assumes it is the day and month of the current year (example 1503 becomes 15-03-2013)

NOTE the above examples assume the current date of 30-MAR-2013.

With date format MM-DD-YYYY the default of the single number does not work. The system takes that value and puts in the first component of the date format, which is the month, not the day.
For example: if you enter 15, the system creates a date of 15-03-2013 which is not valid (3rd day of month of 15 of year 2013 does not exist).
Steps To ReproduceSet the system in format MM-DD-YYYY and enter any date field.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0057710)
AugustoMauch (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (manager)
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 (manager)
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 (manager)
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 (developer)
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 (developer)
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 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


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker