Top Menu

Jump to content
    Global modules

    Global modules

    • Home
    • Projects
    • Activity
    • Work packages
    • Gantt charts
    • Calendars
    • Team planners
    • Boards
    • News
    Home
    Home
Help
    Getting started
    • Introduction video
  • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support
  • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation

User menu

Sign in
Forgot your password?

or sign in with your existing account

OpenProject ID Google

Side Menu

Collapse project menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • News
  • Forums

Content

Expand project menu

Updated by Christophe Bliard 4 days ago

### Steps to reproduce

1. Install OpenProject 13

2. Create multiple tasks and set estimated time

3. Have some tasks with 570 comments

4.
Set some arbitrary remaining time and a mismatching/unproportional completion percentage

5. 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?

<br>

NOTE: This bug causes almost the entirety of old/pre-existing projects and tasks to be unusable, untouchable due to users&#39; browsers hanging and server silently refusing changes/updates

* The migration to v14+&#39;s new time/percentage behaviour is inaccurate and miscalculates percentages

* Example: 0.25h estimated, remaining 0.06h

* Percentage should be 76% but ends up as 75% during migration

* ~~Once Once the mismatch exists in the newer version, the webinterface seems to &quot;endlessly?&quot; loop recalculation clientside due to the mismatch~~ After analysis, it appears the issues comes from the large number of comments on some tasks (570+) mismatch

* Browsers slow down and freeze the moment you open the view to a task

* Especially chromium-based browsers are affected

* Especially on middle to lower end or older hardware (Intel 3rd/4th gen, faster but still noticable on 6th)

* Firefox also slows down but wont freeze as extremely

* Profilers pinpoint these to polyfill library and callstacks go to mutationobservers/callbacks

* Removing the callbacks through browser-extensions like tampermonkey massively increases web performance, but breaks .. input validation and actually saving changes to backend

* !!! This may help pinpointing

* When opening tasks that arent affected- as long as they have a referenced task with that issue, the browser still experiences significant slowdown

* Creating new tasks and viewing or editing these works fine without performance impact

* Tring to update such tasks, like start/end-date etc have a silent 422 error, so pressing on save ends up doing nothing

* Only once you open the estimated/remaining-time and percentage popups, it will show you (in red, on % completed), that the number is mismatching the time values

* This seems... pointless? Given v14&#39;s changelog stated that this value is system calculated, not user input, so why validate?

* \=&gt; this issue on progress values has been extracted in <mention class="mention" data-id="66592" data-type="work_package" data-text="##66592">##66592</mention>&nbsp;


\*\*WORKAROUND (\*\*Works,



**WORKAROUND (**Works,
but hacky): Manual DBupdate using this query:  query:&amp;nbsp;

* update work\_packages set done\_ratio = ((estimated\_hours-remaining\_hours)/estimated\_hours\*100) where estimated\_hours IS NOT NULL and estimated\_hours != 0;

* \=&gt; this fixes the unability to save work packages, but does not fix the performance issue



### What is the expected behavior?

1. Openproject auto-corrects the percentage on load (serverside)

2. WebInterface wont hang


### **Logs**

_There are no logs in the browser nor backend on this._
_However, looking at browsers&#39; inbuilt profilers, the issues track down to &quot;extremely long css animations&quot; and 10s+ of javascript cputime (polyfill) most likely due to looping mutation observers/callbacks caused by validation failures (clientside)_

### 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/769615/content">

\=&gt; this issue on progress values has been extracted in <mention class="mention" data-id="66592" data-type="work_package" data-text="##66592">##66592</mention> 


### 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_

Back

Loading...