This fixes#6393 by modifying the constraint to use an IN condition
which supports both Postgres and SQL Server. Previously, the `|` (OR)
condition was only supported by Postgres because SQL Server only
supports AND conditions.
The implementation follows suggestions from @gasman in
https://github.com/wagtail/wagtail/issues/6393#issuecomment-732161057:
* Migration 0050 is modified to not break on SQL Server
* Added migration 0060 to add or replace the constraint
Additionally, this allows for and documents a `DATABASE_DRIVER` env
variable to be set for testing, to allow a different SQL Server driver
(e.g. FreeTDS on Mac/Linux); and adds the specific `host_is_server`
option for FreeTDS (won't affect SQL Server Native Client on CI).
This PR adds the 'choose' permission discussed in #4488. It limits Image and Document choosers to showing only those Collections (and their contents) for which the current user has the Choose permission.
It grants Choose permissions to the Root Collection to every existing Group that has the "Can access Wagtail admin" perm, via data migration. So there will be no change in behavior unless the user goes in and alters the Choose perms for their site's groups.
This PR has no effect on anything except choosers. The Image and Document index pages are still controlled solely by the 'add' and 'change' permissions, as those are only accessible by users who have those permissions in the first place. This means that it's now possible to configure a Group to allow its members to choose images from existing Collections when editing pages, *without* them being able to edit said images or add new ones.
Make sure document chooser pagination preserves the selected collection when moving between pages
Co-authored-by: Alexander Sajzew <a.sajzew@alexsa.de>
Co-authored-by: Thibaud Colas <thibaudcolas@gmail.com>
Move code from https://www.codista.com/en/blog/wagtail-instagram-new-oembed-api/ into core
Add custom oembed finder for Facebook
Apply suggestions from @originell's code review
Co-authored-by: Luis Nell <luis.nell@codista.com>
FIXUP More places to change the exception name (and a linter fix)
Extend Instagram/Facebook tests to check HTTP request
Add documentation for omitscript parameter
* Handle get_supported_language_variant returning a language variant not in LANGUAGES
Fixes#6539
* Handle LANGUAGE_CODE that isn't in LANGUAGES
* Release note for #6547
Fixes#6540
There are various code paths where Page.localized and similar can be called even when WAGTAIL_I18N_ENABLED is False, and since it's entirely likely that hand-rolled i18n mechanisms and ad-hoc configuration changes (e.g changing LANGUAGE_CODE) will break the Locale model's assumptions about how things are meant to work, we need to provide sensible fallback behaviour for when the current active locale, or the default locale as per LANGUAGE_CODE, does not have a corresponding Locale record:
* Locale.get_active() will fall back on the default LANGUAGE_CODE locale, or raise Locale.DoesNotExist if that one does not exist either;
* TranslatableMixin.localized (along with Page.localized and Page.localized_draft) will handle a missing Locale record by falling back on the default LANGUAGE_CODE locale, or failing that, returning self.
Fixes#6510 and #6511
Catch the LookupError from get_supported_content_language_variant so that if the active language is not one that is recognised as a content language, the URL prefix will be left unchanged from the page's reported locale.
Additionally, skip the `translation.override` when WAGTAIL_I18N_ENABLED is false; this accounts for the fact that existing sites may have used alternative / custom i18n implementations involving i18n_patterns, and on these sites we can't rely on the page's locale field to be meaningful. That way, we restore the pre-2.11 behaviour: if the existing i18n code was using some kind of wrapper around the get_url_parts call, then that will work again; and if not, the URL will reflect the current active locale, which is no worse than before.
Fixes#6518
If the models.py containing a custom user model directly or indirectly imports wagtail.admin.auth, this causes a circular dependency because wagtail.admin.auth attempts to import django.contrib.auth.views, which in turn depends on the custom user model. Fix this by moving the django.contrib.auth.views import inside reject_request.
* Catch PermissionDenied exceptions in require_admin_access decorator
* Fixed permissions errors for the documents views
* Added permissions tests for the images views
* Fixed some tests for limited permissions
* fixes#6352
Matt Westcott