Partially addresses #2401; adapted from #2463.
Updates the explorer-nav logic to take the user's permissions into account.
The menu now begins at the closest common ancestor node of all pages they
have add/edit/publish/lock permission for - as a result, users with
permission over a specific deep section of the tree don't have to redundantly
drill down to it, and we're a step closer to true 'multi-homed' installations
where the user is not made aware of tree structure that exists outside of
their own remit.
Nested objects that are defined using RelatedFields were being mapped into Elasticsearch using the parent model's mapping.
For example, if we index a page with tags, the tags were being mapped with the Page mapping instead of the Tag mapping.
This doesn't make any difference for Elasticsearch 1, but Elasticsearch 2 needs to prefix fields if there are defined on a child model and it was doing this across the related fields as well.
This fix is covered by the tests coming in the Elasticsearch 2 backend.
We need to prefix some fields in Elasticsearch 2 but not Elasticsearch 1. Moving this code into the ElasticsearchMapping class allows us to override it.
It also makes sense to have this sort of thing in the backend rather than the core as other search backends we add in the future may want different behaviour as well.
Save is handled by the 'is this a form submission' check, and preview was probably
never needed at all (preview opens in a new window and does not unload the page,
unless there's a validation error, which is handled separately)
When the page edit form is redisplayed on validation errors, we set alwaysDirty on the
dirty form handler logic so that navigating away triggers the unsaved changes warning
even if no further changes are made. However, the old code tested `form.errors`, which
fails to catch validation errors originating from formsets.
The Jinja2 template config here isn't currently used at all - having
the same APP_DIRS / DIRS config as the Django template engine (which
has higher precedence) means that it will never be selected for
rendering templates, and the existing jinja2 tests bypass Django's
template engine selection and call the jinja2 engine directly.
By giving jinja2 templates their own dedicated location, we can reliably
control which engine is used for which templates.
Ever since the test settings got their own file, this has pointed to
the 'tests' folder instead. Luckily this had no ill effects, since
it's only used as the base for the temporary STATIC_ROOT / MEDIA_ROOT
folders.
