This avoids having to reset the subject first and having to save the automatic subject in an after_perform.
This is especially useful if no change is performed at all. Without the change, even without a change saving would lead to a new journal
The API v3 was allowing reading/writing internal comments when both the
enterprise token doesn't allow it and when the project setting is disabled.
Reading (GET):
- Added EnterpriseToken check to internal_visible scope
Writing (POST):
- Added project.enabled_internal_comments check to CreateNoteContract
https://community.openproject.org/wp/66592
Previous check of % complete consistency with work and remaining work
was allowing a small range of % complete values. For instance with work
= 0.25h and remaining work=0.06h, it was allowing the range 76..77. But
when setting % complete to 75%, the derived remaining work would be
0.06h so 75% value *is* valid.
The fixed check is now simpler: it checks if the % complete value is the
one that would be calculated from work and remaining work, or if the
remaining work value is the one that would be calculated from work and %
complete.
A module has been extracted to ensure the same methods are used to
calculate the values in both validation and derivation.
Validation will only take place when the project_phase_definition_id value is changed. Before, it was always validated (unless the project was changed).
But with the larger amount of possibilities to disable project phases and with subsequent changes to the work package potentically being done by somebody
who does not have the permission to change the value, the validation needs to be more precise.
https://community.openproject.org/wp/64203
When updating a work package to be parent of itself, `closure_tree` gem
has hooks to update the work_package_hierarchies table and can detect
cycles. When a cycle is detected, it adds a "You cannot add an ancestor
as a descendant" error on `:parent_id`.
The fix is to remove this error before providing our own error message.
If duration is negative or garbage, an error is displayed in the date
picker. It will not display any derivation-related errors for start and
due dates. For instance if start date is set, due date is not set, and
duration is invalid, then it won't display "can not be set to null as
start date and duration are known" error for due date.
As the work and remaining work values are rounded to two decimals, it
can lead to strange result of % complete computation and validation.
Two examples:
- A derived % complete of 99.9% should not be rounded to 100% because there is still
some work remaining. It should be 99% in this case.
- Setting work to 2h and remaining work to 1.999h should not lead to 99%
complete because remaining work will be rounded to 2h, so % complete
should be 100% in this case.
These really are edge cases.
In this case, do not tell that % complete should be set when work and
remaining work are set if remaining work is greater than work. No need
to overwhelm the user.
Oliver Günther