Content
View differences
Updated by Markus Kahl over 9 years ago
The bugfix for the following bug was made for 6.04. that further exploits `$pristine` for checking which fields are edited and require resetting after the user changed an attribute.
\#\#23859
This ticket resides as a reminder to solve the existing exploitation of `$pristine` using the following rough sketch:
- Attributes in the work package resource itself always reflects the last server change.
- When editing a field, a `changeset` is registered with the previous value and the value the user is editing.
- Saving a work package translates to saving the active changeset(s). Only the changed attributes are transmitted to the API.
- (Optional, keep in mind for future changes): The server may respond not only with 409 conflict, but with changes the frontend needs to incorporate.
- When the user starts editing another field while the first is saving, a new changeset is created and potentially merged with the previous changeset (e.g., when the first request fails to save).
\#\#23859
This ticket resides as a reminder to solve the existing exploitation of `$pristine` using the following rough sketch:
- Attributes in the work package resource itself always reflects the last server change.
- When editing a field, a `changeset` is registered with the previous value and the value the user is editing.
- Saving a work package translates to saving the active changeset(s). Only the changed attributes are transmitted to the API.
- (Optional, keep in mind for future changes): The server may respond not only with 409 conflict, but with changes the frontend needs to incorporate.
- When the user starts editing another field while the first is saving, a new changeset is created and potentially merged with the previous changeset (e.g., when the first request fails to save).