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).
`field_as_li.html` merely wraps a <li> and includes `field.html`.
Remove `field_as_li.html` template
It is no longer used.
Historical mention in 1.0 release notes [^1] has
been left intact.
[^1]: docs/releases/1.0.rst
Relates to #9031
This was an oversight for a particular case where:
a non-translatable snippet model uses DraftStateMixin and
has PublishingPanel defined in the panels definition.
The `if` check is done so that the status side panel is hidden
if there's no meaningful info to be shown in the panel, which
is the case when you're creating a plain snippet without any
mixin enabled.
Previously, the check only shows the status side panel on create view if
the model is translatable (by checking `view.locale`). When support for
scheduled publishing for snippets was added, the check should also
consider this case, so that the publishing schedule can be set during
creation.
The old text is confusing, as it might be interpreted as
'the publishing schedule only takes effect after the publishing has happened',
which doesn't make sense.
- Add error counter badge to the toggle icon
- Replace draft schedule info message box with an error message box if
the configured schedule is invalid
- Use the correct color for the "Once published"/"Invalid schedule" text
according to designs
