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.
This avoids separate lookups during render_html and render_js_init, and means that shared logic such as building the edit-view URL can be accessed outside of template rendering (so that we can pass it to chooser.setState in the Javascript chooser API, for example).
Passing the model instance means that logic such as rendering thumbnails and generating URLs to edit pages ends up on the template. This is bad because we're going to want to populate these widgets through mechanisms other than rendering the template (e.g. setState on the widget's Javascript API), and that would end up duplicating the logic on the template.
This will make them easier to manage when they need to be passed through additional levels of indirection between the Python widget code and the eventual call to createPageChooser, e.g. in PageChooserBlock.
It's a really small thing, but I honestly feel like Cynthia did most of the work of taking my workaround to production quality code and pushing it over the finish line. So she should be first here.
... when using the ``WAGTAILIMAGES_IMAGE_MODEL``/``WAGTAILDOCS_DOCUMENT_MODEL`` settings.
We can't really support this as we add new fields and methods to these base classes which all images/documents must support. If we did want to support swapping out the models entirely, every addition we make to the base models could be a breaking change.
* Force __str__ of Locale to be a string
* Put some translation proxies in to test settings
* Fixed import in wrong place
* Added test for gettext in LANGUAGES to the Locale model
Co-authored-by: Andreas M <am@zauberberg-medien.de>
This change makes several improvements:
* Use in-memory SQLite database for test migrations
The default database is SQLite but its NAME (which SQLite uses as the
filename) was `wagtail`, which isn't valid since
the wagtail codebase already has a `wagtail/` directory. Trying to
run migration creation commands
(https://docs.wagtail.io/en/latest/contributing/developing.html#running-migrations-for-the-test-app-models)
produced an error:
django.db.utils.OperationalError: unable to open database file
because of this conflict.
This change uses an in-memory database as the default database for
tests. If DATABASE_NAME were set to a real file name, then
running the migration command with SQLite creates an empty db with
this filename on running `django-admin`.
Other non-SQLite engines continue to use the original `wagtail` name,
meaning that the `test_wagtail` database gets created just as before.
* Modifies the default values for database USER, PASSWORD, HOST etc to
being an empty string rather than None, to match Django's
[defaults](https://docs.djangoproject.com/en/stable/ref/settings/#host).
This helps avoid any potential issues when Django and database engines
are expecting this being a string.
* Adds documentation to `developing.rst` regarding installation of
required database modules and available environment variables for database
connection customisation
* Normalises the DATABASE_PASSWORD tests environment variable to match
the name in Django's database settings object
This (hopefully) fully replicates the old behaviour of stream_data, returning raw JSON data for lazy StreamValues and the tuple representation for non-lazy values.
It seems quite likely that the lack of nice representations for these in the shell / debugger is what stopped people from realising that they could index StreamValue as an array, and led them towards stream_data instead ("ooh, this looks like an array of data... I know how to deal with this")
This matches the old behaviour of stream_data for lazy StreamValues. Given that a lazy StreamValue is what you get as standard when retrieving a model instance from the database (or from a PageRevision), any existing user code that casually tinkered with stream_data unaware of the lazy versus non-lazy gotcha is almost certainly expecting it to behave this way - therefore in 99% of cases those users should be able to replace `stream_data` with `raw_data` and have their code work as before, with the added bonus that it won't fall over on page previews (which get their data from a form submission in Python format rather than JSON, and are thus NOT lazy).
Since stream_data existed in lazy (JSONish dicts) and non-lazy (tuples containing native values) variants, retrieval and serialisation each required two separate code paths. We now have a single representation, consisting of the raw JSONish data in _raw_data (unused if we were initialised with native data) and a cache of StreamChild objects in _bound_blocks (prefilled if we were initialised with native data).
Matt Westcott