Content
View differences
Updated by Klaus Zanders over 1 year ago
**As** a project controller
**I want** be able to enforce time records with start and end time
**so that** I can comply with time tracking policies of project sponsors that need this information.
**Acceptance criteria**
* Activating this functionality with a new feature flag.
* There is a global setting in Administration -> Time and costs -> Settings to activate/deactivate "Time records with start and end time" (toggle switch)
* Transform the log time dialog to Primer and add primer forms.
* Add the fields for **Date**, **Start time** and **Finish time** and **Hours**.
* The times are local times for the user so they depend on the time zone chosen by the user. (Reasoning: Users do not think in time zones. We might need to output their current time zone for confirmation)
* The selection of dates will remain the date flatpicker. For the selection of time ~~the the 24h time flatpicker will be user~~ we will use HTML5 time input fields. user.
* The **Hours** can be automatically derived if **Start time** and **Finish time** are introduced. Also the other way around if **Hours** and one if the times is set the other value should be derived automatically.
<figure class="table op-uc-figure op-uc-figure_align-center"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Exact time tracking setting is off</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Only hours field is present</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Only start time / finish time / hours is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">No effect</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Start time and finish time is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Hours calculated as time between</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Start time is filled, hours is then filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Finish date calculated as Start time + hours</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Hours is filled, then finish time is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Start time calculated as End time - hours</p></td></tr></tbody></table></figure>
* The user can still manually enter work time by filling the mandatory fields. The mandatory fields are **Date** and **Hours,** **User** and **Work package** (in My spent time).
* There might be custom fields defined for time entries. In that case, those need to be shown as well.
* When using the track time functionality inside of a work package add the time when the user clicked the start button as Start time and the stop time when the user Stops the tracking.
* The new fields are added to the time entry resource in the API v3 endpoint and schema
* Ensure the dialog includes the fields in all cases:
* Log time from work package
* Log time from _My time spent_ widget in _My page_
* Editing a time logged from the _Time and costs_ reports
* There is a global setting that makes start and finish time a mandatory field for all projects (on|off).
**Implementation sketch / notes**
* We currently store `spent_on` and `hours`. For instances/projects with exact time logging disabled, this will remain the two fields to be filled
* New structure:
* `spent_on` like it is now ,date field
* `hours` like it is now, decimal field with worked hours as decimal
* `start_time` new field, minutes between 0 and 1439 to track start time
* `time_zone` new field, timezone identifier that is copied over from the user on creation
* `start_datetime` (name TBD), virtual column calculated from spent on + start\_time converted from time\_zone to UTC
* `end_datetime` (name TBD), virtual column calculated from spent on + start\_time + hours converted from time\_zone to UTC
**Out of scope**
* Logging including break times. If implemented, a break will be a separate activity, not a time entry
* Preventing overlapping time records for one user on two different work packages. This is addressed in a separate feature.
* Primerization of the action menu that triggers the log time dialogs (e.g., in work packages)
> How should the errors look like. Without visual aid, and with multiple work packages already tracked for the day. It might be very hard to find the slots that are still available for logging time. Proposal: Instead of having just fields to insert into, show the day with the times already logged blocked (showing which work package blocks it) just like a calendar.
* Project-specific settings to make hours mandatory per project.
> \[open\] The specification states to be able to set the start/finish time as mandatory on project level. This means that the project will have to be known to display the '\*' next to the fields. The project is only known once the work package is known. This does not pose a problem in case the time is logged from the work package. But in case the my page widget or the "Time and cost reports" are used as a starting point. The user might have to go back up in the modal after having chosen the work package which makes for a bad user experience.
* Setting that defines a maximum number of hours a user can log per day e.g. 8 h or 24 h.
> We introduced this limitation a while back and removed it again as people complained saying that they used the functionality to bulk add time logs for their team. With the "Maximum log time" setting in place, users wanting a limit could still enforce it while those that don't, can remove the limitation.
**I want** be able to enforce time records with start and end time
**so that** I can comply with time tracking policies of project sponsors that need this information.
**Acceptance criteria**
* Activating this functionality with a new feature flag.
* There is a global setting in Administration -> Time and costs -> Settings to activate/deactivate "Time records with start and end time" (toggle switch)
* Transform the log time dialog to Primer and add primer forms.
* Add the fields for **Date**, **Start time** and **Finish time** and **Hours**.
* The times are local times for the user so they depend on the time zone chosen by the user. (Reasoning: Users do not think in time zones. We might need to output their current time zone for confirmation)
* The selection of dates will remain the date flatpicker. For the selection of time ~~the
* The **Hours** can be automatically derived if **Start time** and **Finish time** are introduced. Also the other way around if **Hours** and one if the times is set the other value should be derived automatically.
<figure class="table op-uc-figure op-uc-figure_align-center"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Exact time tracking setting is off</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Only hours field is present</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Only start time / finish time / hours is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">No effect</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Start time and finish time is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Hours calculated as time between</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Start time is filled, hours is then filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Finish date calculated as Start time + hours</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Hours is filled, then finish time is filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Start time calculated as End time - hours</p></td></tr></tbody></table></figure>
* The user can still manually enter work time by filling the mandatory fields. The mandatory fields are **Date** and **Hours,** **User** and **Work package** (in My spent time).
* There might be custom fields defined for time entries. In that case, those need to be shown as well.
* When using the track time functionality inside of a work package add the time when the user clicked the start button as Start time and the stop time when the user Stops the tracking.
* The new fields are added to the time entry resource in the API v3 endpoint and schema
* Ensure the dialog includes the fields in all cases:
* Log time from work package
* Log time from _My time spent_ widget in _My page_
* Editing a time logged from the _Time and costs_ reports
* There is a global setting that makes start and finish time a mandatory field for all projects (on|off).
**Implementation sketch / notes**
* We currently store `spent_on` and `hours`. For instances/projects with exact time logging disabled, this will remain the two fields to be filled
* New structure:
* `spent_on` like it is now ,date field
* `hours` like it is now, decimal field with worked hours as decimal
* `start_time` new field, minutes between 0 and 1439 to track start time
* `time_zone` new field, timezone identifier that is copied over from the user on creation
* `start_datetime` (name TBD), virtual column calculated from spent on + start\_time converted from time\_zone to UTC
* `end_datetime` (name TBD), virtual column calculated from spent on + start\_time + hours converted from time\_zone to UTC
**Out of scope**
* Logging including break times. If implemented, a break will be a separate activity, not a time entry
* Preventing overlapping time records for one user on two different work packages. This is addressed in a separate feature.
* Primerization of the action menu that triggers the log time dialogs (e.g., in work packages)
> How should the errors look like. Without visual aid, and with multiple work packages already tracked for the day. It might be very hard to find the slots that are still available for logging time. Proposal: Instead of having just fields to insert into, show the day with the times already logged blocked (showing which work package blocks it) just like a calendar.
* Project-specific settings to make hours mandatory per project.
> \[open\] The specification states to be able to set the start/finish time as mandatory on project level. This means that the project will have to be known to display the '\*' next to the fields. The project is only known once the work package is known. This does not pose a problem in case the time is logged from the work package. But in case the my page widget or the "Time and cost reports" are used as a starting point. The user might have to go back up in the modal after having chosen the work package which makes for a bad user experience.
* Setting that defines a maximum number of hours a user can log per day e.g. 8 h or 24 h.
> We introduced this limitation a while back and removed it again as people complained saying that they used the functionality to bulk add time logs for their team. With the "Maximum log time" setting in place, users wanting a limit could still enforce it while those that don't, can remove the limitation.