Re: GLOBAL_PERMS
So, I've taken a different approach, following Markus' idea, and added "app_label" to Permission. I probably still need to add a check to ensure you don't set app_label _and_ content_type, but that can wait for now. You can now define new app-level permissions on the app's AppConfig.permissions [optional]. I've also implemented a "create_app_permissions" function which will ... do just that. Call it whenever you like :) Basic tests are working, as well as added ones. No documentation or changelog as yet... -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0314c0c1-0ebc-6d6b-a7ff-47a428e926b6%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
Re: GLOBAL_PERMS
On 12/31/2017 11:51 AM, Josh Smeaton wrote: - I dislike the seetings approach of GLOBAL_PERMS and would rather see users writing explicit data migrations. I don't favour either setting or migration based perms, but if you're going to go with migration based, then please also consider adding a first class permission type, to avoid the ceremony of creating forward/back functions, and having to remember the model layout for Permissions. Something like: migrations.CreatePermission(app_label, permission_name) Certainly, if we go the data migration path I'd go this way... -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0f67a5d7-dfa0-c31d-5f69-c9f0490dbf8f%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
Re: GLOBAL_PERMS
On 12/31/2017 12:50 AM, Markus Holtermann wrote: Thanks Curtis, I had a quick look. Some thoughts (in no particular order): - IMO a nice idea. I've attached all model independent permissions to the user model in the past to work around the limitation. Certainly a good one I'll remember to mention on #django next time it comes up :) - How do you envision 3rd party apps handling their own permissions? If I install 2 independent apps and both use a permission can_do_foo, one can't distinguish between those two, right? I had considered this, and yes would much rather some sort of per-app permissions. For some years now the model-centric view many people take of their designs has bothered me. - What do you think about adding an 'app_label' to the Permission model that can be used instead of a content type. That could solve the issue from the previous point? content_type and app_label would be exclusive? Oh, absolutely! A solid mechanism for per-app permissions would win me over in a second. Would we keep the existing syntax of "{scope}.{codename}" and fallback scope from model to app label? Or have a different syntax for app-level permissions, like "{app_label}:{codename}"? And if so, how would that be handled in templates? Also would we add get_app_permissions() to the auth API? - I dislike the seetings approach of GLOBAL_PERMS and would rather see users writing explicit data migrations. I was specifically aiming for something almost as simple as the per-model custom permissions. Could we add it to AppConfig? Feels like the right place to me. -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6c4eaa19-6add-2841-be34-7da37ae6625d%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
Fellow Report - December 30, 2017
Triaged --- https://code.djangoproject.com/ticket/28959 - Clicking "No, take me back" on the delete selected inline foreign key / one-to-one field confirmation page does nothing (accepted) https://code.djangoproject.com/ticket/28961 - Convert result of predicate in the function django.utils.functional.partition to bool (wontfix) https://code.djangoproject.com/ticket/28950 - ArrayField.has_changed() returns True for unchanged fields (accepted) https://code.djangoproject.com/ticket/28913 - If MIGRATIONS_MODULES has a missing top-level package, proper error message is not displayed (accepted) https://code.djangoproject.com/ticket/28965 - Update cookie date format to follow RFC2616 (accepted) https://code.djangoproject.com/ticket/28966 - Document that the UUID URL path converter requires dashes (fixed) https://code.djangoproject.com/ticket/28920 - AlterModelManagers migration is generated for all Models with custom Managers, which is not compatible with Django 1.8 (invalid) https://code.djangoproject.com/ticket/28953 - makemigrations with specified app label tries to connect to other databases that are not directly related (needsinfo) https://code.djangoproject.com/ticket/28935 - Template error raised in an {% extends %} child template shows incorrect source location on debug page (accepted) https://code.djangoproject.com/ticket/28852 - Search in admin can't use index when several fields are in `search_fields` (wontfix) Authored -- https://github.com/django/django/pull/9506 - Moved generic_inlineformset_factory tests to a separate file. https://github.com/django/django/pull/9499 - Refs #28965 -- Deprecated unused django.utils.http.cookie_date(). Reviewed/committed -- https://github.com/django/django/pull/9373 - Fixed #28731 -- Added an error message when using an empty Q() in a When expression. https://github.com/django/django/pull/9487 - Fixed #28944 -- Fixed crash when chaining values()/values_list() after QuerySet.select_for_update(of=()). https://github.com/django/django/pull/9493 - Fixed #28930 -- Simplified code with any() and all(). https://github.com/django/django/pull/9491 - Fixed #28958 -- Fixed admin changelist crash when using a query expression in the page's ordering. https://github.com/django/django/pull/9303 - Fixed #28714 -- Added system checks for invalid model field names in Meta.indexes. https://github.com/django/django/pull/9387 - Fixed #28841 -- Added ForcePolygonCW GIS function and deprecated ForceRHR. https://github.com/django/django/pull/9463 - Fixed #28926 -- Fixed loss of precision of big DurationField values on SQLite and MySQL. https://github.com/django/django/pull/9383 - Fixed #25817 -- Made RenameField repoint to_field/to_fields references. https://github.com/django/django/pull/9454 - Fixed #28912 -- Made EmailMessage.message() exclude an empty To field. https://github.com/django/django/pull/9385 - Fixed #14642 -- Fixed generic inline formsets crash when using save_as_new=True. https://github.com/django/django/pull/9500 - Fixed #28117 -- Added a helpful message in loaddata when psycopg2 can't load a fixture due to NUL characters. https://github.com/django/django/pull/9499 - Fixed #28965 -- Updated cookie date format to follow RFC 7231. https://github.com/django/django/pull/9512 - Fixed #28918 -- Fixed Model.refresh_from_db() for instances hidden by the default manager. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/96c815fa-68c2-405e-9853-f58c16634c62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GLOBAL_PERMS
> > > - I dislike the seetings approach of GLOBAL_PERMS and would rather see > users writing explicit data migrations. > I don't favour either setting or migration based perms, but if you're going to go with migration based, then please also consider adding a first class permission type, to avoid the ceremony of creating forward/back functions, and having to remember the model layout for Permissions. Something like: migrations.CreatePermission(app_label, permission_name) or django.contrib.auth.CreatePermission (which is actually an Operation) if we want to avoid contrib polluting migrations proper. I haven't fully thought through the implications, but every time I need to write a data migration I spend more time than I'd like to admit searching for a previous data migration from which to copy. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/32bb32b4-bf1a-494e-8588-df70f8abfef7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GLOBAL_PERMS
Thanks Curtis, I had a quick look. Some thoughts (in no particular order): - IMO a nice idea. I've attached all model independent permissions to the user model in the past to work around the limitation. - How do you envision 3rd party apps handling their own permissions? If I install 2 independent apps and both use a permission can_do_foo, one can't distinguish between those two, right? - What do you think about adding an 'app_label' to the Permission model that can be used instead of a content type. That could solve the issue from the previous point? content_type and app_label would be exclusive? - I dislike the seetings approach of GLOBAL_PERMS and would rather see users writing explicit data migrations. /Markus On Sat, Dec 30, 2017 at 08:31:57PM +1100, Curtis Maloney wrote: So, after a discussion with a new user on #django today I decided to make "permissions not bound to models" a first-class feature. So I've written a simple patch that is in https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1 Basically: 1. Allow Permission.content_type to be null 2. Adjust everything else to cope with that 3. Add new setting "GLOBAL_PERMS" 4. Teach create_permissions to honor that. 5. Write minimal test and documentation. Would welcome further input. -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1a028faa-beb1-7e67-69a7-a9c1028a4e17%40tinbrain.net. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20171230135038.GA29952%40inel.local. For more options, visit https://groups.google.com/d/optout.
Re: Overhaul extra_requires to include more optional dependencies
Thank you for looking into this! Another benefit alongside ease of install and discoverability, is that it makes the requirements files of projects using Django more self-documenting (in that it avoids stray dependency entries that appear to be unused, but actually aren't - and so need a comment to explain what uses them). See also the related open ticket https://code.djangoproject.com/ticket/27682. Re the single package entries, I think there is still value in having them, so long as they are named by feature rather than by package name. eg `Django[crypto]` vs `Django[bcrypt]`. This allows the particular choice of library to be a Django implementation detail that can be adjusted without needing requirements file changes. Ed On Monday, 11 December 2017 10:26:11 UTC, jr...@leukeleu.nl wrote: > > Django has a number of optional features that require the installation of > additional Python packages. > > > Right now it's possible to $ pip install Django[bcrypt,argon2] to install > Django and the optional packages (at the correct minimum version) required > for bcrypt/argon2 support. > > > However this is not possible for other optional features, like > database/cache backend, gis, certain image related features etc. > > I've created a pull request adding the optional dependencies found in the > test requirements: https://github.com/django/django/pull/9440 / > https://code.djangoproject.com/ticket/28905 > > So end users can do things like: > > > $ pip install Django[mysql,sqlparse,images,memcached] > $ pip install Django[postgresql,gis] > $ pip install Django[selenium,test-parallel] > > > Not only would this make it much easier to install a particular > combination of Django and optional dependencies correctly, it also makes > some of the optional features/dependencies a little bit more discoverable. > This might not the full set of optional dependencies, or the right > grouping/naming, so a review is more than welcome (i.e. should sqlparse > be added to the mysql/oracle extra requirements? Should a sqlite extra be > added that only includes sqlparse?). > > Besides adding this to setup.py, additional changes to the documentation, > test instructions and scripts, code warnings etc. will probably be > necessary. > > If anyone objects to adding these extra requirements I'd also like to hear > about it. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8cb27037-757b-4d19-893f-0e4cd83700c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
GLOBAL_PERMS
So, after a discussion with a new user on #django today I decided to make "permissions not bound to models" a first-class feature. So I've written a simple patch that is in https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1 Basically: 1. Allow Permission.content_type to be null 2. Adjust everything else to cope with that 3. Add new setting "GLOBAL_PERMS" 4. Teach create_permissions to honor that. 5. Write minimal test and documentation. Would welcome further input. -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1a028faa-beb1-7e67-69a7-a9c1028a4e17%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.