#29843: Create permissions using migration operations rather than using the
post_migrate signal
-------------------------------------+-------------------------------------
Reporter: Petter Strandmark | Owner: Arthur
Type: | Rio
Cleanup/optimization | Status: assigned
Component: contrib.auth | Version: 2.1
Severity: Normal | Resolution:
Keywords: contenttypes | Triage Stage: Accepted
permissions post_migrate |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> What do you think about triggering a
post_contenttypes_operations_injection signal so that django.contrib.auth
can register to it and do its create/update permission injection then?
This could work but an alternative could be to add a system check or raise
`ImproperlyConfigured` if `django.contrib.auth` is installed before
`django.contrib.contenttypes`.
If this assertion holds then the `pre_migrate` signal registered by `auth`
is guaranteed to run after the one registered by `contenttypes` as it was
registered after. That would allow the `auth` operation injection logic to
look for `AddContentType` and `RenameContentType` operations in the plan
and insert `AddPermission` and `RenamePermission` after them.
We already [https://docs.djangoproject.com/en/2.1/ref/middleware
/#middleware-ordering document] and perform
[https://github.com/django/django/blob/dc5e75d419893bde33b7e439b59bdf271fc1a3f2/django/contrib/auth/middleware.py#L17-L23
similar checks] for middleware ordering so I think doing it for
`INSTALLED_APPS` could work as well. Thing is this check would fail for
most of the projects at first
[https://github.com/django/django/blob/dc5e75d419893bde33b7e439b59bdf271fc1a3f2/django/conf/project_template/project_name/settings
.py-tpl#L35-L36 since the project template has been ordering them the
other way around] for a while. I still think this is worth enforcing a
form of ordering for installed apps for this purpose though and I'd
volunteer to work on a PR to tackle this.
Whether we choose a system check or an `ImproperlyConfigured` preceded by
a period deprecation warning we should still register the `post_migrate`
signals for a few releases if apps are not ordered appropriately. This
would allow the contenttypes creation and permissions to still work in
most of the cases until the deprecation ends of if some users ignore or
silence the system check.
Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/29843#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.866ca0c91fd88a3ced413237b0a0c5fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
