Content
Updated by Christophe Bliard about 10 hours ago
Originally bug report ##66552 from which there was 2 issues. This one is about the inaccurate progress values after migration.
### Steps to reproduce
1. Install OpenProject 13
2. Create multiple tasks and set estimated time
3. Set some arbitrary remaining time and a mismatching/unproportional completion percentage
4. Upgrade to version 14 or higher
Context: We've migrated from the latest 13.x branch version to latest 14.x, then upgraded PostgreSQL to v17 and moved OpenProject straight to 16.2.2 right after that
### What is the buggy behavior?
* The migration to v14+'s new time/percentage behaviour is inaccurate and miscalculates percentages
* Example:
* before migration: estimated time = 0.25h, remaining time = 0h, done ratio = 75%
* during migration to version 14, remaining time gets calculated to 0.0625h, then rounded to 0.06h
* after migration: estimated time = 0.25h, remaining time = 0.06h, done ratio = 75%
* Percentage should be 76% but ends up as 75% during migration
* Trying to update such tasks fails because of validation errors with a 422. For start/end-date the error is silent, so pressing on save ends up doing nothing. It's because it's a modal.
* Once you open the estimated/remaining-time and percentage popups, it will show (in red, on % completed), that the number is mismatching the time values
* This seems... pointless? Given v14's changelog stated that this value is system calculated, not user input, so why validate?
\*\*WORKAROUND (\*\*Works, but hacky): Manual DBupdate using this query:
* update work\_packages set done\_ratio = ((estimated\_hours-remaining\_hours)/estimated\_hours\*100) where estimated\_hours IS NOT NULL and estimated\_hours != 0;
### What is the expected behavior?
1. OpenProject auto-corrects the percentage on load (serverside)
2. OpenProject does not display an error if the value is inside an acceptable range
### Analysis
This happens because progress values are rounded all the time when derived from the other: work and remaining work values are rounded to 2 decimal places. % complete is rounded to integer.
When validating values coherence, when work is very low there is a range of acceptable values for % complete. Similarly, when work is very high, there is a range of acceptable values for remaining work. work.
The validations currently do not account for this precision loss and displays an error if the % complete value is not the one given by the computation.
This is not limited to migration to version 14. It also happens on a live instance:
**Other reproduction steps**:
* Open the progress modal
* Set work to 0.25h
* Set % complete to 75%
* \=> remaining work is derived to 0.06h and an error is displayed, depsite being calculated by the app.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/770617/content">
**Another reproduction steps**:
This one uses status based to force using 75% and rounded remaining work
* Use status-based mode
* Set "in-progress" status to be 75% complete
* set a work package to have status = in-progress and work = 0.25h
* \=> remaining work gets updated to 0.06h
* Now switch back to work-based mode
* Then try to open the progress modal => error about % complete mismatch is displayed
* Or try to change Priority => error 422 due to % complete mismatch
### Screenshots and other files
Example error. Context: manually removing the 75% will make it auto-fill back to 75%, setting remaining time to 0 or setting the percentage to 76% fixes the current task/package.
Once the bug has been fixed, the browser will auto-complete the % to the correct 76% instead if one attempts to blank the field.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/770606/content">
### Environment information
**OpenProject installation type**
* Selfhosted, Packaged installation
* Ubuntu 20.04.6 LTS
**OpenProject version**
_16.2.2_
**Browser**
* [x] Chrome
* [x] Firefox
* [ ] Safari
* [ ] Mobile Safari
* [ ] Other (please specify)
**Operating System**
* [x] Windows
* [ ] Mac OS X
* [ ] Mobile iOS
* [ ] Mobile Android
* [ ] Linux (please specify distro)
* [ ] Chrome OS
* [ ] Other (please specify)
**Language**
_English and German_
### Steps to reproduce
1. Install OpenProject 13
2. Create multiple tasks and set estimated time
3. Set some arbitrary remaining time and a mismatching/unproportional completion percentage
4. Upgrade to version 14 or higher
Context: We've migrated from the latest 13.x branch version to latest 14.x, then upgraded PostgreSQL to v17 and moved OpenProject straight to 16.2.2 right after that
### What is the buggy behavior?
* The migration to v14+'s new time/percentage behaviour is inaccurate and miscalculates percentages
* Example:
* before migration: estimated time = 0.25h, remaining time = 0h, done ratio = 75%
* during migration to version 14, remaining time gets calculated to 0.0625h, then rounded to 0.06h
* after migration: estimated time = 0.25h, remaining time = 0.06h, done ratio = 75%
* Percentage should be 76% but ends up as 75% during migration
* Trying to update such tasks fails because of validation errors with a 422. For start/end-date the error is silent, so pressing on save ends up doing nothing. It's because it's a modal.
* Once you open the estimated/remaining-time and percentage popups, it will show (in red, on % completed), that the number is mismatching the time values
* This seems... pointless? Given v14's changelog stated that this value is system calculated, not user input, so why validate?
\*\*WORKAROUND (\*\*Works, but hacky): Manual DBupdate using this query:
* update work\_packages set done\_ratio = ((estimated\_hours-remaining\_hours)/estimated\_hours\*100) where estimated\_hours IS NOT NULL and estimated\_hours != 0;
### What is the expected behavior?
1. OpenProject auto-corrects the percentage on load (serverside)
2. OpenProject does not display an error if the value is inside an acceptable range
### Analysis
This happens because progress values are rounded all the time when derived from the other: work and remaining work values are rounded to 2 decimal places. % complete is rounded to integer.
When validating values coherence, when work is very low there is a range of acceptable values for % complete. Similarly, when work is very high, there is a range of acceptable values for remaining work.
The validations currently do not account for this precision loss and displays an error if the % complete value is not the one given by the computation.
This is not limited to migration to version 14. It also happens on a live instance:
**Other reproduction steps**:
* Open the progress modal
* Set work to 0.25h
* Set % complete to 75%
* \=> remaining work is derived to 0.06h and an error is displayed, depsite being calculated by the app.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/770617/content">
**Another reproduction steps**:
This one uses status based to force using 75% and rounded remaining work
* Use status-based mode
* Set "in-progress" status to be 75% complete
* set a work package to have status = in-progress and work = 0.25h
* \=> remaining work gets updated to 0.06h
* Now switch back to work-based mode
* Then try to open the progress modal => error about % complete mismatch is displayed
* Or try to change Priority => error 422 due to % complete mismatch
### Screenshots and other files
Example error. Context: manually removing the 75% will make it auto-fill back to 75%, setting remaining time to 0 or setting the percentage to 76% fixes the current task/package.
Once the bug has been fixed, the browser will auto-complete the % to the correct 76% instead if one attempts to blank the field.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/770606/content">
### Environment information
**OpenProject installation type**
* Selfhosted, Packaged installation
* Ubuntu 20.04.6 LTS
**OpenProject version**
_16.2.2_
**Browser**
* [x] Chrome
* [x] Firefox
* [ ] Safari
* [ ] Mobile Safari
* [ ] Other (please specify)
**Operating System**
* [x] Windows
* [ ] Mac OS X
* [ ] Mobile iOS
* [ ] Mobile Android
* [ ] Linux (please specify distro)
* [ ] Chrome OS
* [ ] Other (please specify)
**Language**
_English and German_