Content
View differences
Updated by Marc Alcobé over 1 year ago
**As a project team member**
**I want to** enter a start and end time when creating time entries
**so that** my company can deliver detailed time sheets for the project controlling and invoicing.
**Use case**
Some customers require detailed time sheets when I bill them. They do not only want to see how long I have been working on a task, but also when I started and ended. Start and end-time can be very important for interventions outside normal business hours, because they are sometimes billed at a higher rate.
**Acceptance criteria**
* Transform the dialog to Primer and add primer forms.
* Add the fields for **Date**, date, **Start time** and **Finish time**, **Breaks** time and **Hours**.
* \[open\] Assumption. The times are local times for the user so they depend on the time zone chosen by the user.
* The **Hours** should be automatically calculated 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.
* \[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.
* **Breaks** time should always be extracted from the total **Hours**.
* The user can still manually enter work time by filling the mandatory fields. The mandatory fields are **Date** (User, Start date and **Hours,** **User** and **Work package** (in My spent Total worked time).
* \[open\] The specification is not clear on whether "Start date" is always a mandatory field.
* The selection of dates will remain the date flatpicker. For the selection of time the 24h time flatpicker will be user.
* \[open\] There might be custom fields defined for time entries. In that case, those need to be shown as well.
* 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
* 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.
* A user can not log time multiple times on the same minute.
* \[open\] In case "Start time" is mandatory: What value to set the already existing time entries' start times to.
* The function will include this new settings:
* Project settings -> Time tracking (renamed from _Time tracking activities_):
* Primarise the page and rename it
* Divide the content in this sections:
* Mandatory fields: settings require exact times and require comments.
* Activities: select which activities can be used
* Maximum log times: input the hour limit per day to log per user.
* \[open\] What are the default when seeding and when migrating existing projects.
* Administration settings -> Time and costs -> Defaults (renamed from _Settings_):
* Primarise the page and rename it
* Ensure the title of the page is the same as in the side menu
* Divide the content in two tabs:
* Time: establish the defaults for costs in new projects
* Costs: establish the defaults for costs in new projects
* Error cases:
* User trying to log more than 24h in a single day
* \[open\] 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.
* Log hour limit per user exceeded
* \[open\] Overlapping times between two work packages are probably also prohibited. 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.
**Out of scope**
* Redesign or improve the times and costs pages.
* Allowing multi-day log time.
* \[open\] Reworking the my page widget to show the exact times is probably out of scope.
**Implementation**
* 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) \[?\]
**Figma and visuals**
https://www.figma.com/design/xRFTkBJYxQJxwAf9fd3oM1/Log-time?node-id=310-6194
**I want to** enter a start and end time when creating time entries
**so that** my company can deliver detailed time sheets for the project controlling and invoicing.
**Use case**
Some customers require detailed time sheets when I bill them. They do not only want to see how long I have been working on a task, but also when I started and ended. Start and end-time can be very important for interventions outside normal business hours, because they are sometimes billed at a higher rate.
**Acceptance criteria**
* Transform the dialog to Primer and add primer forms.
* Add the fields for **Date**,
* \[open\] Assumption. The times are local times for the user so they depend on the time zone chosen by the user.
* The **Hours** should be automatically calculated 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.
* \[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.
* **Breaks** time should always be extracted from the total **Hours**.
* The user can still manually enter work time by filling the mandatory fields. The mandatory fields are **Date**
*
* \[open\] There might be custom fields defined for time entries. In that case, those need to be shown as well.
* 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
* 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.
* A user can not log time multiple times on the same minute.
* \[open\] In case "Start time" is mandatory: What value to set the already existing time entries' start times to.
* The function will include this new settings:
* Project settings -> Time tracking (renamed from _Time tracking activities_):
* Primarise the page and rename it
* Divide the content in this sections:
* Mandatory fields: settings require exact times and require comments.
* Activities: select which activities can be used
* Maximum log times: input the hour limit per day to log per user.
* \[open\] What are the default when seeding and when migrating existing projects.
* Administration settings -> Time and costs -> Defaults (renamed from _Settings_):
* Primarise the page and rename it
* Ensure the title of the page is the same as in the side menu
* Divide the content in two tabs:
* Time: establish the defaults for costs in new projects
* Costs: establish the defaults for costs in new projects
* Error cases:
* User trying to log more than 24h in a single day
* \[open\] 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.
* Log hour limit per user exceeded
* \[open\] Overlapping times between two work packages are probably also prohibited. 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.
**Out of scope**
* Redesign or improve the times and costs pages.
* Allowing multi-day log time.
* \[open\] Reworking the my page widget to show the exact times is probably out of scope.
**Implementation**
* 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)
**Figma and visuals**
https://www.figma.com/design/xRFTkBJYxQJxwAf9fd3oM1/Log-time?node-id=310-6194