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
The workflow models can always be imported via wagtail.models even if workflow is disabled.
Instead of checking the import with try/except, we should check the setting instead.
