Content
View differences
Updated by Klaus Zanders about 17 hours ago
**As** a resource manager
**I want to** track for each user in the system on what weekdays they work, how many hours per day they work, when they are not available
**so that** I can properly plan my resources.
**Acceptance criteria**
* Add new feature flag "User Working Times"
* We might move this to a setting in the future that enables the working time tracking
* Add new global permissions
* Own working hours can be accessed via Account Settings -> Schedule and Availability
* Working hours for other users can be accessed via Administration -> Users and permissions -> click on a user -> find 2 new tabs
* For every user in the system it is possible to track
* Working days
* How many hours per day they work.
We chose this over a weekly work time so we can properly overlay this with work packages
* An _availability factor_. We acknowledge that users will not always work 100% on project work. Daily business and other stuff happens. So we can specify this factor (i.e. user works 40hrs per week, availability factor of 80% --> 32hrs of resource availability)
* Vacation times and other unavailable days should be trackable. For privacy reasons, no more details than just unavailable days should be tracked (i.e. no differentiation between holidays and sick days)
* Calendar view similar to the global non-working days
* Global non-working days are shown in the personal availability calendar
* The availability per user should be changeable by the API
* Availability times have a start date to prepare for changes
* Modification should be handled by new tabs in the user edit page.
* Calendar view for non working times with basic features:
* If you are allowed to add, you can select dates in the calendar and the modal will show up with the dates prefilled
* Resizing the boxes in the calendar is not intended to change the dates. You can click on a calendar event and it will open a modal to edit or delete
* The working days defined by the system (Administration -> Calendar and dates -> Working days) are shown in white, all other days are grayed out
* Systemwide non working days are shown in pinkish color in the calendar
* When creating a time-off that crosses systemwide non working days, those are not considered in the calculation:
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/919528/content">
In this example 2 days is correct, because friday is a system-wide "holiday" and sat & sun are not mrked as working days
**Technical notes**
* Availability times should be logged like hourly rates. With a starting date. That will work properly with users switching from full to part time, etc
* Old availability records cannot be edited but new ones can be added.
* The only exception: When a working hours record is set to start today, it is edited in place as we cannot have multiple entries per day
* Future schedules can be edited.
**Permissions and visibility considerations**
* Users can always view their own times via Account Settings -> Schedul and availability
* New global permissions
* Manage own working times
* Manage working times for all users
**Translation considerations**
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">EN</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">DE</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">FR</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">ES</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Availability</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Verfügbarkeit?</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td></tr></tbody></table></figure>
**Out of scope**
* We do not want to become an HR system. So things like vacation requests, etc will not be implemented
* The UI to manage the data is a help for smaller customers. We expect the data to mostly be injected into our system by an external service (HR system, etc) via the API
**I want to** track for each user in the system on what weekdays they work, how many hours per day they work, when they are not available
**so that** I can properly plan my resources.
**Acceptance criteria**
* Add new feature flag "User Working Times"
* We might move this to a setting in the future that enables the working time tracking
* Add new global permissions
* Own working hours can be accessed via Account Settings -> Schedule and Availability
* Working hours for other users can be accessed via Administration -> Users and permissions -> click on a user -> find 2 new tabs
* For every user in the system it is possible to track
* Working days
* How many hours per day they work.
We chose this over a weekly work time so we can properly overlay this with work packages
* An _availability factor_. We acknowledge that users will not always work 100% on project work. Daily business and other stuff happens. So we can specify this factor (i.e. user works 40hrs per week, availability factor of 80% --> 32hrs of resource availability)
* Vacation times and other unavailable days should be trackable. For privacy reasons, no more details than just unavailable days should be tracked (i.e. no differentiation between holidays and sick days)
* Calendar view similar to the global non-working days
* Global non-working days are shown in the personal availability calendar
* The availability per user should be changeable by the API
* Availability times have a start date to prepare for changes
* Modification should be handled by new tabs in the user edit page.
* Calendar view for non working times with basic features:
* If you are allowed to add, you can select dates in the calendar and the modal will show up with the dates prefilled
* Resizing the boxes in the calendar is not intended to change the dates. You can click on a calendar event and it will open a modal to edit or delete
* The working days defined by the system (Administration -> Calendar and dates -> Working days) are shown in white, all other days are grayed out
* Systemwide non working days are shown in pinkish color in the calendar
* When creating a time-off that crosses systemwide non working days, those are not considered in the calculation:
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/919528/content">
In this example 2 days is correct, because friday is a system-wide "holiday" and sat & sun are not mrked as working days
**Technical notes**
* Availability times should be logged like hourly rates. With a starting date. That will work properly with users switching from full to part time, etc
* Old availability records cannot be edited but new ones can be added.
* The only exception: When a working hours record is set to start today, it is edited in place as we cannot have multiple entries per day
* Future schedules can be edited.
**Permissions and visibility considerations**
* Users can always view their own times via Account Settings -> Schedul and availability
* New global permissions
* Manage own working times
* Manage working times for all users
**Translation considerations**
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">EN</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">DE</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">FR</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">ES</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Availability</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Verfügbarkeit?</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br data-cke-filler="true"></p></td></tr></tbody></table></figure>
**Out of scope**
* We do not want to become an HR system. So things like vacation requests, etc will not be implemented
* The UI to manage the data is a help for smaller customers. We expect the data to mostly be injected into our system by an external service (HR system, etc) via the API