Enable / disable the open-modal button on reaching the limit, as we do for InlinePanel's standard add button; and when handling the response from the modal, stop adding new items when max_num is reached
We keep data-chooser-url in the HTML output, and use it as a fallback in the JS - for backwards compatibility with existing BaseChooser subclasses that don't pass an options dict (such as AdminTaskChooser, which overrides render_js_init)
At this point we've been turning the 'opts' dict from a private API specific to PageChooser, that more or less transparently passes options on to the modal as URL query parameters, into a convention shared across all chooser widgets where the question of "will this option become a URL parameter" is an internal implementation detail. Since this is notionally a bundle of JS variables rather than a bundle of URL params, we should take this opportunity to consistently adopt camel case, before this pattern becomes widespread in third-party code and ends up as a mishmash of camel-case and snake-case.
The old signature is still accepted for backwards compatibility.
This then matches the signature of the other chooser widget JS classes, allowing PageChooserFactory to extend the generic ChooserFactory.
This will allow us to refactor it, including adding class-level references to window.PageChooser and window.PageChooserModal as necessary, without dealing with the possibility of telepath/widgets.js being imported before the includes that define those.
This matches the implementation in components/ChooserWidget. This change breaks the tests that pass a jQuery collection object rather than a DOM element, but that was never valid in the first place as per https://docs.wagtail.org/en/stable/reference/streamfield/widget_api.html - fix the tests accordingly.
Previously, anything invoking the chooser modal needed to make its own call to ModalWorkflow, which meant it needed to import the corresponding 'onloadHandlers' dict, know the appropriate chosen response identifier to listen to, and know how to modify the chooser URL to pass parameters (if applicable). This would mean a lot of duplicated logic if there were multiple places where the modal is invoked.
Here we introduce a ChooserModal base class which encapsulates those details - a caller just needs to instantiate it with the base URL, and call `open` on it to open the modal (passing an options dict and a response callback).
- Revise 'redirect' from a string to a 'continue' boolean that defaults to false
- Use 'continue=true' for cases where we do not want to create a next param on submit that takes the user back to the current page
- Fixes #9815
- Fix any issues in files being ignored
- Fixed linting errors where appropriate
- Include some rules being ignored in the src/components folder
- Closes #8731
* Add a border around the userbar menu in Windows high-contrast mode so it can be identified
* Make sure browser font resizing applies to the userbar
* Switch userbar to initialise a Web Component to avoid styling clashes
* Refactor userbar stylesheets to use the same CSS loading as the rest of the admin
