Currently, the code that handles the POST request for reverting a
revision lives in the EditView class, while the revisions_revert view is
a smaller view that tries to "mimic" the EditView for rendering the view
as part of a GET request. The view injects the revision ID into the
form, which has the action URL hardcoded to the EditView. Including the
revision ID in the form allows the EditView to tell whether it's in a
"reverting" mode or not, and adjust the POST logic accordingly.
However, this results in possible inconsistencies in both views.
Whenever we want to change EditView code or template, we need to make
sure to also update the revisions_revert view. The fact that the
revisions_revert view is a function-based view doesn't help.
Instead of copying the view code and reusing the template with the
addition of injecting the revision ID in the form, turn it into a proper
subclass of the EditView, and make use of Django's URL patterns to
retrieve the revision ID in the EditView.
This approach is similar to how reverting revisions is handled for
snippets.
Ideally, all the code for handling revisions revert should live in the
RevisionsRevertView, and the EditView shouldn't know about it at all.
This is how it's done for snippets: all the revisions revert-related
code is put in RevisionsRevertMixin.
However, this is currently not possible for pages without more
significant refactoring, so this commit does the minimal change needed
to achieve the goal of keeping the revisions_revert view in sync with
the EditView.
- window.buildExpandingFormset and using the base class `ExpandingFormset` can now be deprecated.
- Move the window global setting to core.js which avoids the need to add the import in editor_js, to align with other future deprecations in core.js
- Add upgrade considerations in release notes
- `ExpandingFormset` is still needed for other existing usage (InlinePanel/MultipleChooserPanel)
- Add additional JSDoc and updates to Eslint to advise developers that this feature is not to be used for new code
- Use the Wagtail admin formset mixin to adopt new data attributes on core form parts
- Update the edit/create templates to put the attributes on the remaining elements
- Add basic unit tests for smoke testing data attributes
- Remove CSP incompatible inline scripts approach
- Remove the now unused standalone static build/imports for the group edit view as this will not be needed
- Update Eslint accordingly
- Use the Wagtail admin formset mixin to adopt new data attributes on core form parts
- Update the edit/create templates to put the attributes on the remaining elements
- Add basic unit tests for smoke testing data attributes
- Remove CSP incompatible inline scripts approach
- Remove the now unused standalone static build/imports for the group edit view as this will not be needed
- Ensure that the edit workflow form does not render any JS or attributes when the pages are not actually editable (workflow disabled)
- Leverage the new Django 4.0 feature `deletion_widget` for formsets to attach data attributes and make the input a HiddenInput for existing and 'blank' forms.
- Add support for data attributes used by the new Stimulus FormsetController
Replaces the core functionality in `client/src/components/ExpandingFormset/index.js` and the Delete callbacks in other usage of the `window.buildExpandingFormset` function.
Provides limitations on add/delete once the min/max have been reached but does not set up any disabling of these buttons as this is currently in the remit of `InlinePanel`.
Includes a full test suite for error handling, updating inputs and nested usage which leverages Stimulus' scope management.
Does not rely on any id attribute structure or wrangling.
Relates to #7915
Also add commented-out assertions that log entries are only created
once for each search pick, which currently would fail due to a bug in
the implementation.
Move the individual form validation to the SearchPromotionForm class
instead of the formset.
Do not assume external_link_url and the other fields are available in
cleaned_data, which can cause a crash if the input is invalid.
Attach validation errors to the most relevant section instead of bunging
everything as a non-field error.
Jake Howard