Content
Updated by Oliver Günther 1 day 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 24h time flatpicker will be 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">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">Duration 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, duration is then filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Finish date calculated as Start time + duration</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Duration 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 - duration</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**
* Store start and end date-time in the database (easy for finding double-bookings for a single employee) or store start date-time and duration (easier implementation when start and end time is not used and for migration of existing data)
**Out of scope**
* 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 24h time flatpicker will be 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">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">Duration 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, duration is then filled</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Finish date calculated as Start time + duration</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Duration 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 - duration</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**
* Store start and end date-time in the database (easy for finding double-bookings for a single employee) or store start date-time and duration (easier implementation when start and end time is not used and for migration of existing data)
**Out of scope**
* 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.