[7.0] hr_timesheet_sheet - timesheet start and end are without timezone as it is date instead of datetime

Bug #1204224 reported by Yannick Vaucher @ Camptocamp
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Medium
OpenERP R&D Addons Team 3
OpenERP Community Backports (Addons)
Status tracked in 7.0
7.0
Fix Released
Medium
Unassigned

Bug Description

When entering attendances you might encounter serious issue as depending on the timezone, the attendances won't go on the correct timesheet.

This is due because a timesheet has its start and end date defined in as DATE format. Thus it will mean timesheet start and end have no timezone defined.

On the other hand, attendances will be in user timezone. This lead to attendances which will be out of scope of their timesheet if the timesheet was in local timezone too.

Now let's say that a DATE in database means the timesheet is in users' timezone. Because a date isn't precise to be converted without overlapping from UTC to local timezone. And because it doesn't make sens for an Australian business to have its timesheets in UTC.

Then we need to match attendances to this local timezone when trying to match the sheet_id on attendance. And as we have no timezone field defined on timesheet what we can do is taking this information from the employee.

See linked MP

Related branches

Revision history for this message
Bill Ennals (bennals) wrote :

Hi Yannick,

The bug below that I posted in May:

https://bugs.launchpad.net/openobject-addons/+bug/1179893

is still present and although it appears related to your bug, almost seems to be the opposite, ie. the attendance time stamp is not recorded (or perhaps converted) correctly within the database according to a users timezone.

And you're right about a business in Australia...no sense at all:)

Thanks,

Bill
Brisbane, Australia

Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Yannick Vaucher @ Camptocamp (yvaucher-c2c) wrote :

@Bill, did you try my patch to solve your issue? Does it help?

Revision history for this message
Bill Ennals (bennals) wrote :

Hi Yannick,

Sorry for the late reply. Yes, I did try to patch hr_timesheet_sheet.py with the code changes you made but after restarting the server I couldn't connect to openerp from a browser. I got a message saying 'no handler found', so I think I may have made a mistake in patching the python file (I'm not very experienced with this stuff). Replacing the patched file with the original fixed the problem with connecting.

Looks like a release may not be far away anyway!

Thanks,

Bill.

Revision history for this message
Bill Ennals (bennals) wrote :

There was a fix committed for this bug several months ago now. Will the fix be merged into the stable 7.0 releases soon?

Thanks,

Bill.

Revision history for this message
Bill Ennals (bennals) wrote :

Hi Yannick,

I just installed the latest nightly stable release which I presume should have the fix for this bug but unfortunately my bug (linked above) still exists, so either it's not related to this bug or I've done something wrong that's causing it. I've attached screenshots showing the persistent problem where the attendance record is time stamped with UTC+0 time rather than UTC-10 (Brisbane Australia) which seems to lead to a sign in at the start of the timesheet week being allocated to the previous timesheet week and the resultant error that the timesheet does not contain and even number of sign ins and sign outs.

I wait in hope I guess...

Bill

Revision history for this message
Bill Ennals (bennals) wrote :
Revision history for this message
Yannick Vaucher @ Camptocamp (yvaucher-c2c) wrote :

@Bill the patch was released in ocb-addons only -> https://code.launchpad.net/~ocb/ocb-addons/7.0
It hasn't been release in official addons. Thus it won't be present in nightly build.

ocb-addons is a copy of openobject-addons maintained by the community in which there are different restrictions and in which we tend to merge some specific fixes faster as OpenERP SA hasn't the ressources to deal with all the waiting MP.

If you have an OPW you should use it to ask OpenERP to release this patch earlier.

Revision history for this message
Houssine (houssine-bakkali) wrote :

Hi Yannick,

problem is that with a support contract you get a patch for your bug report but then the patch stay pending for merging for months...

A nice thing would be to have also a nightly build for the ocb branch...

Revision history for this message
Yannick Vaucher @ Camptocamp (yvaucher-c2c) wrote :

@Houssine you might want to say a little word on

https://lists.launchpad.net/openerp-community/msg03563.html

There is a current talk about OCB branches

Revision history for this message
Bill Ennals (bennals) wrote :

Ah, I see. Thanks Yannick. I'll try and get my head around bazaar again - last time I think I gave up on it.

Bill.

Revision history for this message
Bill Ennals (bennals) wrote :

Thanks Yannick. Your fix seems to work well. I'm very grateful.

Bill.

Revision history for this message
Yannick Vaucher @ Camptocamp (yvaucher-c2c) wrote :

Hello Bill,

Thanks for your feed back.
Nice to know we made it working for the other side of the planet.

Let's hope OpenERP will take time to apply the fix in their official branch as well...

Cheers

Revision history for this message
Houssine (houssine-bakkali) wrote :

@Yannick,

I was following this conversation until the mail 68 ;) no enough time to read all the thread in the train or at home.

But I'll give a try to catch back the thread or maybe run a new one on this specific subject.

tags: added: hr sheet timesheet
Revision history for this message
Martin Trigaux (OpenERP) (mat-openerp) wrote :

Hello,

We have merged attached MP

revno: 10019 [merge]
revision-id: <email address hidden>

Changed in openobject-addons:
status: Confirmed → 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.