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.
