Ticket modified by mgorski Maciej at 2012/11/30 13:32
Tracking System - Bugs
Category - Timesheet
Version - Version 1.8.004
Status - Closed
Resolution - Works for me
Completed - 0%
Priority - 5 - medium
Created by - Florian Zörkler
Created on - 2011/04/26 16:58
Assigned to - Ralf Becker
Summary - #2944 - Bug in Timesheet: Different Owner and Modifier at one Entry
I've some problems with timesheets entries:
The user can only set up new entries for himself, but when he saves them, they will be written on another user.
timesheet table is looking like this:
77852 Project Title NULL 1303285620 360 6 NULL 122 16 1303828106 88 NULL NULL
The uid 88 is the modifiers one, where 16 is the owner. The modifier is the user that has written this entry
What is the problem there?
Comment by mgorski Maciej at 2012/11/30 13:32:
Any ideas how to solve problem.
I't looks like this is problem with DB engine that is setting ts_owner to actual logged in user..
Comment by mgorski Maciej at 2012/10/18 16:53:
Any ideas how to fix it or where to look the bug?
In my opinion it is sirious problem, when using system by larger group of users.
Time sheet is a key feature.
Comment by mgorski Maciej at 2012/09/07 12:38:
We have this problem every month when people adds entries to the timesheet.
We are using LDAP autorization.
When I try to add new entry it just do not appear on my list. Sometimes it happens with several entries one after another.
In database those lost entries goes to another existing user. ts_modifier field is ok, but ts_owner is some random user.
It happens every month (when everybody fills their timesheets) with xx entries added by differnt users.
When I filled my timesheet it looked like:
I have added 15 entries properly, then 3 next went to someone else (i have checked in DB) and the rest few added properly.
Does anybody have the solution or any idea?
Comment by Tracking System at 2012/01/11 10:07:
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days.
Comment by Birgit Becker at 2011/09/20 13:50:
have you solved that problem or does it still persist?
I could imagine that having different uids and account-ids used in ldap and the sql-database can cause this problems.
I would recomment to buy support for that issue and update/change the ids in the sql-database to use the same you have already in the ldap. This needs to be done via some scripts. But this is something we can only do via support ...
Comment by Florian Zörkler at 2011/07/01 08:06:
This issue is at least up to date.
Yesterday, all of our co-workers made timesheet entries and they've lost a lot of them, appearing on different people.
Are there any possibilities vor concrete logging?
Or is there anybody having the same issue?
Operating System is Debian Squeeze with 2.6.32-5-amd64 Kernel.
egw Version is 1.8 Rev 34120 (SVN)
The Account Database is on another Server using OpenLDAP Server slapd 2.4.23
Comment by Florian Zörkler at 2011/05/12 13:18:
Today i've got an event alert.
The e-mail address of the Sender was completely different from the owner of this alert.
So i think, that the function that is looking for the current user has some problems.
This might be an Authentication Problem, i think.
So, all of our users authenticate with a LDAP Tree. This tree is harmonized with a Samba Domain- Infrastructure, so I imported the UIDs from the local samba databse. The UIDs on the local egw Database have been different ones. So I configured egw to store the Account Data on SQL, but authenticate with LDAP...
The UIDs in local egw Database are from 1 up to 200 or so, in LDAP, UIDs begin at 1000, so i can say, that the LDAP UIDs have not been seen in local Database. But could this be a problem with the function, that looks which uid has opened the session?
At least, if my point isn't clear enough, i could send you an e-mail in german
Comment by Florian Zörkler at 2011/05/04 09:07:
Another colleague has sent me a Screenshot with exactly the same issue. I've attached it.
Some additions to the screenshot:
The User "Gunnar" is in a special group for controlling issues. So he has rw Rights for everyones timesheet.
The User "Sören" made this entry. He has only the right to make timesheet entries on his own name.
Comment by Florian Zörkler at 2011/04/27 08:54:
"What do you mean with same entry in a project? Only identical internal id makes to elements the same. "
I meant different entries with the same content. But that answeres my question :)
I can not reproduce this behaviour.
The user can only write new entries on his own name (there is no selection box on the top of the edit window)
Sometimes, it works.
Sometimes, the entries will be written on another user. Afaik the wrong entries were not completely written to only one wrong user.
At least, he saved the entry with save&new
Comment by Ralf Becker at 2011/04/27 08:27:
first Timesheet ACL has nothing to do with Projectmanager ACL:
- if you have no read rights for an users timesheets, you can see them in PM, but not in timesheet
- if you have no edit rights on a project, it tells nothing about having rights on an element of the project
What do you mean with same entry in a project? Only identical internal id makes to elements the same. Users can add (multiple) identical named elements to a project.
Anyway I can not reproduce that behavior. Are you sure the user has not just rights to edit/add new entries for other users and choose that user when he added the timesheet?
Can you reproduce the behavior you describe?
Comment by Florian Zörkler at 2011/04/27 08:08:
I had a little discussion with my Co-Workers last afternoon.
So: What is Timesheet doing, if 2 people are making the same entry on the same project?
Are there 2 separate entries, or will the first one only edit the second one?
What about a possible rights problem in project manager? At least i thought, if the user isn't able to write entries on a special project, he won't see it in timesheet.