Feature #3926
open
Permissions for time tracking
0%
Description
- Redmine should allow to specify, which users/roles can log time for an issue in a specific state.
- It should be possible to prevent time overruns, i.e. logging to issues where the planned time is used up.
Updated by Maxim Krušina about 15 years ago
What is also very import is ability to not-allow adding spent time into the past.
But it's a bit complicated issue, I still dont have exact idea how to solve this.
I guess there should be some configurable time period how deep you can go (add time) into the past.
In real life, developers tends to forget add time, so project managers pushing on devlopers to add their spent time backwards,
but in most (our :) cases it is simething like one or two days ago (in past). Anyway trouble is when we have finished billing and invoice to client and someone add spent time backward ie 14 days ago, then spent time records doesn't correspod to invoiced time and it's a reab trouble, because it's not tracable where is the problem.
I don't know how to solve this easily. One of my ideas was configurable time period (probably per role), ie. we can set let's say 2 days. If developer wannts to add spent time as 5 days ago, there should be some approval by project manager required... anyway it's a bit complicated process...
What others think?
Updated by Thomas Pihl about 15 years ago
Another way would be to have a project field setting a freeze-date on entry. When you write the invoice you move the freeze date and be sure no one backdates any time into the period already invoiced.
It's a crude solution.
Nicer would be to keep track of when the information was entered so you can filter "in" all the time-reports entered during last month even if they report time on some date before. Next issue would then be if you need to change some value that you already reported. Lots of interesting cases here.
My vote would go on freeze-date as a good-enough-solution.
/T
Updated by Eric Davis about 15 years ago
Here's another idea. Freeze the time entries when they are billed and collect what to bill based on what entries haven't been billed yet.
- TimeEntry 1 - 2009-09-20
- TimeEntry 2 - 2009-09-23
Creating a bill for September would freeze those two time entries. Then in October, new time entries were added:
- TimeEntry 3 - 2009-09-21
- TimeEntry 4 - 2009-10-03
When the bill is generated for October, it will see there is a TimeEntry back in September that hasn't been billed yet so it would include it.