Debounce value was changed in the app part, but was not updated in the
test.
Also, changed the way the field is focused to avoid the select to be
opened (because it could stay opened sometimes). And for input fields
being focused, it required to also move the carte to the end of the
input before clearing it. It was not needed before because we used to
click in the field to give focus, and clicking also moves the caret to
the end (most of the time).
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.
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.
I do not like sleep like this. But because I do not manage to find a
better synchronization strategy for the turbo stream to come back and
update values, I prefer something slow and working than something fast
an breaking. Using `page.driver.wait_for_network_idle` does not seem to
wait for long enough as Angular has to do its Angular things to update
the model being created.
Please fix it if you can.
The selector for the progress edit fields varies based on whether it's
in a create or update context. This commit ensures that this
distinction is made when inferring the `#display_selector` method and
provided by the WorkPackageTable object.
* This needs a better solution down the line to deal with the progress
modal being able to deal with intermediate updates without actually
persisting on create pages.
By refactoring ProgressEditModal to inherit from EditField. The class has been renamed to ProgressEditField as it is about editing a field rather than the modal itself.
Kabiru Mwenja