This migration would fail on Wagtail instances that have been around
since v0.5 (when we still used django-south), because the column order
of the wagtailsearch_querydailyhits table is different from the newly-created
wagtailsearchpromotions_querydailyhits.
If you hit this issue, you deserve a 🌟
- Test that uses setTimeout never ran as Tippy relies on `transitionend` events, which JSDom will not dispatch. Rework tests to correctly test this custom event gets dispatched
- Use Stimulus dispatch method for custom event dispatching as the controller name (e.g. 'w-dropdown') will automatically be added, work around TypeScript bug in Stimulus which should be fixed in a future release https://github.com/hotwired/stimulus/issues/642
- Add show/hide methods, pull out options to own get method
- Add unit tests for show/hide, content being in dropdown
- Relates to #10557
- Removes six inline scripts completely, no longer relying on window.headerSearch
- Update the fallback Stimulus Swap controller afterLoad to be a deprecated method
- Add upgrade considerations
- Fix regression from d554cbe310 where manually submitting page search results would load the partial, not full page response
- Closes#9950
Other packages and projects may still rely on the existence of this
template. We cannot simply remove it without a proper deprecation.
Add a note to remove the template in the next release.
- Builds on #9952
- Create a new method `submit` and `submitLazy` to serialise a form's inputs and submit (GET) async to replace content
- Create a lazy version of `replace` and add unit tests for it
- Partial progress on #9950
This is mostly based on ModelAdmin's InspectView, but with
modeladmin-specific code removed and a simpler method signature for the
field display methods.
When the 'choose' permission was introduced in
d18ffb0233, all the logic is put in an
`elif` block. It means that this is only ever checked if the
`foo_any_permission_bar` permission policy methods are called without
'change' nor 'delete' in the actions list.
If the user only has a 'choose' permission, and the method is used
with a list of actions that contains both 'change'/'delete' and
'choose', e.g. `instances_user_has_any_permission_for(user, {'change',
'delete', 'choose'}`, it won't return any results.
This is inconsistent with how the logic for these 'any' methods
should work.
Instead of `elif`, the original implementation should add 'choose' to
the list checked in the previous `if`.
This commit does it slightly differently by enforcing for the known
actions in the beginning of the methods, but it still yields the same
results.
We already have the logic in the code to prevent this, but it mistakenly
used the string 'edit' instead of 'change'. The code checks for the
existence of any of "add", "edit", and "delete" permissions.
Unfortunately, the corresponding tests have both the "add" and "change"
permissions configured, so the tests are passing due to the existence of
the "add" permission.
The old test for the GET request was also incorrect: there is no
permission on a different collection for the user, so the form field is
hidden but not because of the existence of the "add" and "change"
permission. This is fixed by granting a permission to the
finance_collection first, similar to how the POST test is configured.
Two new tests have been added that re-runs the tests but with only the
"change" permission for the user, which fail without the "edit" ->
"change" fix.
In addition, a small performance improvement is added by checking the
cached permissions for the user instead of making an exists() query to
the database.
The existing code identified filters such as `publication_date__year__gt=1950` as ones that can be implemented as a straight comparison on the date. However, it left the right-hand-side expression unchanged, leading to a comparison like `publication_date > 1950`. Apparently this worked up to Elasticsearch 7, but on ES8 it gives spurious results (my best guess is that it's interpreting the integer 1950 as a UNIX timestamp).
Fix this so that it builds the proper comparison expression, based on a datetime.date object of January 1st of the appropriate year.
These tests seem to have been written with the intent of testing query construction independently of actually running the queries; to do this, they mock the relevant bits of elasticsearch-py so that no actual server needs to be running. However, this is a bit of a bodge job - it still instantiates the Elasticsearch object when initialising the backend, so *some* version of elasticsearch-py must be installed to run Wagtail's test suite; and furthermore, that installed version must be able to handle EVERY backend's variant of the `Elasticsearch(...)` constructor, regardless of whether it was written for a completely different version.
This breaks down with Elasticsearch 8, which makes backward-incompatible changes to the constructor. Since the CI suite as a whole will test each backend with its corresponding correct version of elasticsearch-py at some point, it's redundant (and a waste of CPU cycles) to repeat those tests in environments with a different ES version (or none at all).
Sage Abdullah