failing spec: spec/features/work_packages/progress_modal_spec.rb:195
failing run: https://github.com/opf/openproject/actions/runs/21204407008/job/60997306384
In the spec, another page is visited during the test, meaning the
internal ids of the capybara elements may not be the same as the ones
before the page is reloaded. This is a problem because the
`progress_popover` caches the container element, and it's not valid
anymore (it's stale).
One fix could be to create a new `progress_popover` instance after the other page is visited.
I found it better to be able to pass a lambda for the container element
to the `progress_popover` constructor, so that it always gets it afresh
and will never be stale.
The `./spec/features/work_packages/tabs/relations_children_spec.rb`
works better when using `target.click` instead of
`target.trigger('click')`.
The `./spec/features/work_packages/progress_modal_spec.rb` was scrolling
to the middle of the screen when clicking on the work field to display
the progress popover for some reason.
Then when updating the status field on the work package creation page,
it was made active by clicking it, which displayed the dropdown, and
then it was clicked again for the autocompletion, which scrolled at the
top of the page for some reason. Problem is: the dropdown is fixed and
scrolling up make it overlap the status field, and when calling
`target.click`, Capybara refuses saying that something overlaps it.
The adopted solution is to scroll to the top of the page before updating
the status. Not satisfying, but works.
The date picker preview controller and the progress preview controller
were abstracted into a super class. It's too hard to make deep
modifications to the date picker preview controller while keeping the
compatibility with the progress preview controller.
For instance, we break the progress values being formatted on blur
without noticing. This commit adds a test just for this.
This commit undoes some changes made in 5429b8b (commit title is
"Extract logic of the progress modal to be reused for the datepicker
modal").
Once the date picker progress controller works as expected, we'll see
which part can be reused and extracted into an abstraction.
When submitting with invalid values, the progress popover was updated
via turbo-stream with a modal which did not include the touched fields.
This caused the fields to be ignored on the second submit, even if they
appeared to be invalid. This was also causing the preview to not work as
expected.
This has been changed:
- the update is done through a turbo-stream morph instead of an update.
It avoids disconnecting and reconnecting the stimulus controllers.
- the touched fields are now correctly sent to the component for
rendering. The state is maintained in the stimulus controller instead
of the hidden fields. Fields are still needed for form submission.
- the fields sent to the server when previewing are exactly the same as
the ones being sent on submit.
- the turbo_stream commands are sent directly from the controller. None
are sent if the update completed successfully as the modal will be
closed by client side javascript anyway.
- the referrer-field is now just the field name instead of the full
work package key, to reduce noise.
Because of the weird way we initialize the fake work package, it could
believe that the status did not change and no recomputation was needed.
This is an edge case, and I'm not satisfied with its design.
When work is increased or decreased and remaining work is also increased
or decreased by the same amount, indicate the delta in the hint message
to reduce user confusion.
See comments 12 to 18 of work package 57258 for more details.
https://community.openproject.org/wp/57258
It was calculated but not displayed. This is now covered by a feature
test.
In the progress popover, when the input is a select, the event being
listened to to render a preview is `change` instead of `input. It's
because cuprite does not emit the `input` event when selecting an option
in a select input. It only emits `change`. `ProgressEditField` has been
updated to correctly focus and change the value of a select (for
status selection inside the popover).
Also to allow `ProgressEditField#expect_modal_field_value` to work
regardless of the field being disabled or readonly, the disabled value
default to `:all` which matches both disabled and enabled inputs, and
the `readonly` parameter has been removed. To check for it, call
`ProgressEditField#expect_modal_field_read_only` directly instead.
https://community.openproject.org/wp/57512
When work is modified and remaining work and % complete are both empty,
the % complete field should not be untouched because that would lead to
it having a value again, which is tedious when one wants to clear all
values.
If Remaining work and % Complete are both modified and Work is initially
empty, then it will be derived, but if it is set then it's % Complete
and Remaining work which will change.
The goal is to keep the Work value unchanged as much as possible.
Feature flag is percent_complete_edition. So % complete edition will be
shipped but disabled in 14.4.
It will eventually be activated in 15.0 when there will be a total %
complete calculation mode so that we can bundle both features together
in one release.
The values were not retained between modifications of percent values, so
a new parameter `initial` was introduced to "save" the entered values
between edits.
It also fixed the progress modal having empty values when opening it a
second time in the create work package page.
- It's allowed to set only one progress value while the two others are
unset.
- It's not allowed to have two progress values set while the other one
is unset.
- Do not output "inconsistent % complete" error if work < remaining work
to avoid having too many errors displayed at the same time.
https://community.openproject.org/wp/55997
The `duration_format` setting can take two values: "hours_only" or
"days_and_hours". The default value is "hours_only".
The `duration_format` setting is used to determine how durations are
displayed in the frontend and in some exports.
It can be changed in Administration > Calendar and Dates > Working days
and hours.
In status based mode, `remainingTime` is marked as `writable: false`.
The popover edit field tries to write it, but that is ignored when
submitting the creation, and it renders nil instead. When then
submitting, this nil value will be submitted and result in the error
"Remaining work must be set when work is set".
By setting `render_nil: false` for `remainingTime` in the
`WorkPackageRepresenter`, the field is not returned back from the form
endpoint when it is not set. This way, the field is not rendered in the
form on submit, and the error is avoided.
In work-based mode, the remainingTime being not sent back by the form
anymore when it is nil means we have to deal with it being undefined,
which is why the progress popover had to be modified too.
Not sure what is the best way, following fails:
```shell
rspec './spec/features/work_packages/progress_modal_spec.rb[1:4:1:1:1,1:6:1:1,1:6:2:1]' --seed 33667
```
Christophe Bliard