[trunk] datatime search widget looses data

Bug #655266 reported by Ferdinand
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo GTK Client (MOVED TO GITHUB)
Fix Released
Low
OpenERP sa GTK client R&D

Bug Description

example
stock - tracability - stock moves

select a to date - it copies date 00:00:00 into the search

as the date is a datetime it must copy 23:59:59 to include all move of this date

it's critical because there are some dates with time 00:00:00 and some with specific time

try 10/07/2010

Related branches

Revision history for this message
Ferdinand (office-chricar) wrote :

I would suggest the following
for the
* current date-time use now()
* for all past date selected
* for from: use 00:00:00 for time
* for to use: 23:59:59

it's a constant source of (hard to explain) errors

other example - location-structure - selecting a date -
"from" takes selected date + current time - which has to be manually adjusted to 00:00:00
"to" takes selected date + current time - which has to be manually adjusted to 23:59:59

I just want to recall that filtering fields like "create_date" this way might miss some data as the datetime is stored like
 2010-10-09 23:59:59.330704
unlikely but true.

tfr (Openerp) (tfr)
affects: openobject-client → openobject-addons
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
qdp (OpenERP) (qdp) wrote :

it's affecting the gtk client... but i'm not sure of the validity of that bug report :-/

maybe we could set by default the time of "to-date" in a search view as "<selected date> + 23:59:59" instead of "<selected date> + 00:00:00" as it's currently the case (currently same behavior as for "from-date")

affects: openobject-addons → openobject-client
Changed in openobject-client:
assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2) → nobody
Revision history for this message
Ferdinand (office-chricar) wrote :

the proposed solution will improve usability a lot, but in rare cases it might not catch all data if people work around midnight.

Example
 2010-08-06 09:17:17.492114
which is theoretically possible for all fields of type "timestamp without time zone"

example create_date

Revision history for this message
Ferdinand (office-chricar) wrote :

a good example of constant selecting errors for users is
Warehouse / Location Structure /
double click and select from / to
the widget must (at least) return
* from selected date + 00:00:00
* to selected date + 23:59:59 (with the limitation described above).

to be user friendly.
the need for specifying hours+ minutes+seconds will certainly be the exception

Changed in openobject-client:
assignee: nobody → OpenERP sa GTK client R&D (openerp-dev-gtk)
Revision history for this message
Naresh(OpenERP) (nch-openerp) wrote :

Hello,

The best option can be to make the datetime widget as same as the datetime widget available in Form view i.e with
Hours and minutes options So that the user can select the particular datetime.

Thanks,

Changed in openobject-client:
status: Confirmed → In Progress
Revision history for this message
Ferdinand (office-chricar) wrote :

Sorry - you have not got the usability issue

the BEST solution is to propose 00:00:00 for "from" fields and 23:59:59 for "to" fields

everything else is not userfriendly and usually leads to incomplete data selection (and hence bug reports of users)

it is "expensive" to instruct every user to enter the minutes manualy and the usually forget to enter data into these fields.

Revision history for this message
Ravi Gadhia (OpenERP) (rga-openerp) wrote :

Hello
          It has been fixed in ~openerp-dev/openobject-client/trunk-dev-client and will merge with trunk client soon

Thanks

Changed in openobject-client:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.