Re: Django dashboard packages?

[Scot Hacker]

On Tuesday, November 10, 2015 at 6:17:00 PM UTC-8, Allison A. wrote:

> Hi all, 
>
> I'd like to get an idea of what dashboard packages Django developers 
> prefer or are using instead of the out-of-the-box admin. 
>
>
>
1) "Dashboard" could mean literally hundreds of different things. 

2) This is a question for django-users, not for django-developers (which is 
about the development of Django itself). Please re-ask your question on 
django-users, and be sure to describe what it is that you want to 
accomplish.

./s
 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0f7f1cae-c3a8-4bf4-baae-20100f0e3d77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Custom Groups model and interoperability

[Scot Hacker]

I asked this question on django-users and got no response. Thought I might 
have better luck getting an "official" opinion on this here.

You can call blocks in your templates anything you like, but if you intend 
to share your software with the world, you'd better use `{% block content 
%}` if you expect interoperability between your project and 3rd party apps.

My question is along similar lines, but relates to using custom Groups. 
There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
If you make a custom Group model that subclasses Django Group, you can 
still use `user.groups.all()`. But if a project uses a Group model that 
that does not subclass `Group`, that doesn't work of course.

I can't seem to find anywhere in the docs where Django recommends doing it 
one way or another. I've always thought that a custom group should subclass 
Group, and that is common, but some projects apparently don't do it that 
way.

I am asking because I am the maintainer of a reusable app that requires 
groups compatibility, and have come across an app that that uses a 
non-Django-derived groups system. We have come to impasse about the best 
way to support this (or whether to support it all).

Are there any best practices on this question in the Django docs or 
elsewhere?

Thanks,
Scot

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/103ccb2e-cc5e-4b80-97e1-ce983cf8a5e4n%40googlegroups.com.

Re: Custom Groups model and interoperability

[Scot Hacker]

No official (or semi-official) position on this? Is "The right way to 
create custom Groups" simply undefined in Django? 

Thanks.


On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:

> I asked this question on django-users and got no response. Thought I might 
> have better luck getting an "official" opinion on this here.
>
> You can call blocks in your templates anything you like, but if you intend 
> to share your software with the world, you'd better use `{% block content 
> %}` if you expect interoperability between your project and 3rd party apps.
>
> My question is along similar lines, but relates to using custom Groups. 
> There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
> If you make a custom Group model that subclasses Django Group, you can 
> still use `user.groups.all()`. But if a project uses a Group model that 
> that does not subclass `Group`, that doesn't work of course.
>
> I can't seem to find anywhere in the docs where Django recommends doing it 
> one way or another. I've always thought that a custom group should subclass 
> Group, and that is common, but some projects apparently don't do it that 
> way.
>
> I am asking because I am the maintainer of a reusable app that requires 
> groups compatibility, and have come across an app that that uses a 
> non-Django-derived groups system. We have come to impasse about the best 
> way to support this (or whether to support it all).
>
> Are there any best practices on this question in the Django docs or 
> elsewhere?
>
> Thanks,
> Scot
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com.

Re: Custom Groups model and interoperability

[Scot Hacker]

Thanks very much for the response Aymeric. Seems like a bit of a gray area 
that could use some form of recommendation - like in a "Best Practices" 
section of the documentation? In any case, thanks again.

Scot


On Tuesday, October 5, 2021 at 1:13:47 PM UTC-7 Aymeric Augustin wrote:

> Hello,
>
> The semi-official position is "create a separate model with a FK to the 
> auth.Group". I know that's less than helpful. At least you know that 
> there's nothing better built-in.
>
> -- 
> Aymeric.
>
> PS: `{% block content %}` doesn't provide a meaningful level of 
> interoperability. The semi-official position on this is "there is no 
> reasonable way to do pluggable templates".
>
> On 5 Oct 2021, at 19:13, Scot Hacker  wrote:
>
>
> No official (or semi-official) position on this? Is "The right way to 
> create custom Groups" simply undefined in Django? 
>
> Thanks.
>
>
> On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:
>
>> I asked this question on django-users and got no response. Thought I 
>> might have better luck getting an "official" opinion on this here.
>>
>> You can call blocks in your templates anything you like, but if you 
>> intend to share your software with the world, you'd better use `{% block 
>> content %}` if you expect interoperability between your project and 3rd 
>> party apps.
>>
>> My question is along similar lines, but relates to using custom Groups. 
>> There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
>> If you make a custom Group model that subclasses Django Group, you can 
>> still use `user.groups.all()`. But if a project uses a Group model that 
>> that does not subclass `Group`, that doesn't work of course.
>>
>> I can't seem to find anywhere in the docs where Django recommends doing 
>> it one way or another. I've always thought that a custom group should 
>> subclass Group, and that is common, but some projects apparently don't do 
>> it that way.
>>
>> I am asking because I am the maintainer of a reusable app that requires 
>> groups compatibility, and have come across an app that that uses a 
>> non-Django-derived groups system. We have come to impasse about the best 
>> way to support this (or whether to support it all).
>>
>> Are there any best practices on this question in the Django docs or 
>> elsewhere?
>>
>> Thanks,
>> Scot
>>
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/49ecfb95-ac40-4a3c-8f19-40b1f9586f39n%40googlegroups.com.

Re: Custom Groups model and interoperability

[Scot Hacker]

I think a big part of the challenge I'm experiencing with the user of my 
reusable app who has submitted the controversial PR is that the 
"semi-official position" is undocumented in Django. I see a 3 yr old Track 
ticket <https://code.djangoproject.com/ticket/29748> requesting 
implementation of an `AUTH_GROUP_MODEL`  but its status is "Maybe/Someday," 
telling me that there is little interest in adding that to Django (which 
means few people are experiencing it as a problem). 

If I submitted a documentation PR recommending the semi-official position 
as a  Best Practice, would it be likely to be accepted?

Thanks,
Scot


On Tuesday, October 5, 2021 at 9:46:35 PM UTC-7 Scot Hacker wrote:

> Thanks very much for the response Aymeric. Seems like a bit of a gray area 
> that could use some form of recommendation - like in a "Best Practices" 
> section of the documentation? In any case, thanks again.
>
> Scot
>
>
> On Tuesday, October 5, 2021 at 1:13:47 PM UTC-7 Aymeric Augustin wrote:
>
>> Hello,
>>
>> The semi-official position is "create a separate model with a FK to the 
>> auth.Group". I know that's less than helpful. At least you know that 
>> there's nothing better built-in.
>>
>> -- 
>> Aymeric.
>>
>> PS: `{% block content %}` doesn't provide a meaningful level of 
>> interoperability. The semi-official position on this is "there is no 
>> reasonable way to do pluggable templates".
>>
>> On 5 Oct 2021, at 19:13, Scot Hacker  wrote:
>>
>>
>> No official (or semi-official) position on this? Is "The right way to 
>> create custom Groups" simply undefined in Django? 
>>
>> Thanks.
>>
>>
>> On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:
>>
>>> I asked this question on django-users and got no response. Thought I 
>>> might have better luck getting an "official" opinion on this here.
>>>
>>> You can call blocks in your templates anything you like, but if you 
>>> intend to share your software with the world, you'd better use `{% block 
>>> content %}` if you expect interoperability between your project and 3rd 
>>> party apps.
>>>
>>> My question is along similar lines, but relates to using custom Groups. 
>>> There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
>>> If you make a custom Group model that subclasses Django Group, you can 
>>> still use `user.groups.all()`. But if a project uses a Group model that 
>>> that does not subclass `Group`, that doesn't work of course.
>>>
>>> I can't seem to find anywhere in the docs where Django recommends doing 
>>> it one way or another. I've always thought that a custom group should 
>>> subclass Group, and that is common, but some projects apparently don't do 
>>> it that way.
>>>
>>> I am asking because I am the maintainer of a reusable app that requires 
>>> groups compatibility, and have come across an app that that uses a 
>>> non-Django-derived groups system. We have come to impasse about the best 
>>> way to support this (or whether to support it all).
>>>
>>> Are there any best practices on this question in the Django docs or 
>>> elsewhere?
>>>
>>> Thanks,
>>> Scot
>>>
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/123e1852-691d-41b4-a5ce-e111b55e1bbcn%40googlegroups.com.

Re: GLOBAL_PERMS

[Scot Hacker]

On Saturday, December 30, 2017 at 1:32:21 AM UTC-8, 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. 
>

I'd recommend that anyone working on such a feature take a good look at 
django-rules. It works on a per-app or per-project basis, is not 
necessarily bound to models (but can be), has a good system for detecting 
conflicting rules that might be set in different parts of the codebase, and 
provides some nice helpers for keeping statements and conditions concise. 
Useful both for full-view protection and for in-template fragments. I do 
find the distinction is makes between `make_rule` and `make_perm` somewhat 
arbitrary and confusing, but otherwise they've done great work with it so 
far.

https://github.com/dfunckt/django-rules

./s

-- 
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/051b418d-349a-4ada-92ac-42f5b587fbe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Password Validators

[Scot Hacker]

Rather than enforce an arbitrary set of password construction rules, I 
prefer systems that gauge password strength as an overall entropy score, 
then let  sites establish the minimum overall strength they require. How 
that strength is achieved is up to each user - uou can either go short and 
random, or long and memorable. Length trumps pretty much all other factors, 
especially if you disallow strings such as the user's own username, email, 
company name, etc.). Dropbox created a system like this called zxcvbn and 
open sourced it.  It was then ported to python. 

https://github.com/dropbox/zxcvbn
https://github.com/dwolfhub/zxcvbn-python

I use a "roll your own" solution on top of zxcvbn-python in some of my 
projects (in order to show dynamic strength meters in the UI as user 
types), but others have converted it to work as a Django password validator.

https://github.com/Pierre-Sassoulas/django-zxcvbn-password-validator

If Django were to bundle any additional validators, this or something like 
it would have my vote.

./s

-- 
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/de03b9dd-ef24-4ee6-a7fd-287e79304465%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC Proposal (Bundler for Django)

[Scot Hacker]

On Saturday, April 6, 2019 at 6:03:29 AM UTC-7, Ashik Meerankutty wrote:
>
> Please review and comment my draft proposal for GSOC 2019
> Draft 
> 
>

Ashik's proposal is more along the lines of a general asset pipeline, a la 
django-compressor or django-pipeline, rather than a webpack builder. 
Regardless, I count 30+ asset pipeline systems at 
https://djangopackages.org/grids/g/asset-managers/ . 

./s

-- 
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/cf64fba5-120b-4aae-8b9e-4409783bfe99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Scot Hacker]

 Just bringing this up for the sake of thoroughness: 
NOTE: This is a beta product
*Black* is already successfully used by several projects, small and big. It 
also sports a decent test suite. However, it is still very new. Things will 
probably be wonky for a while. This is made explicit by the "Beta" trove 
classifier, as well as by the "b" in the version number. What this means 
for you is that until the formatter becomes stable, you should expect some 
formatting to change in the future. That being said, no drastic stylistic 
changes are planned, mostly responses to bug reports.

Many/most of us use it in production settings already, as the AST check 
guarantees it isn't going to break anything, but the beta status means you 
can't always do a simple `pip install black`, and it means that black's 
formatting choices could change. 

Does a project as significant as Django want to adopt a beta tool whose 
"contract" with its users has not yet stabilized?

I heart black and would be happy to see it in Django but wonder if we 
should wait a bit to hit 1.0.

./s

-- 
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/5d71f95a-1a8a-4db4-a2ac-8a59adde1fb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Scot Hacker]

The written quality of the Django docs has been a selling point for years, 
but discoverability has never been great. I wanted to add two notes:

1) The front page of the docs says docs are organized into four sections 
(Tutorials, Topic Guides, Reference Guides,  How-To Guides). And it's been 
proposed that we add a fifth docstring-generated API Reference as well. But 
remember that most people looking to solve a problem under deadline start 
with search, not taxonomy. Search results do *seem* to be labeled with the 
section of the docs they come from, but the sections referenced don't 
 actually correspond to the four sections we say use!  If I search for 
"forms" I get results that claim to come from "API Reference," "Using 
Django," "Release Notes," which don't match the names of our four sections. 
 I propose that A) search results clearly indicate the doc sections that we 
claim we use for organization; B) Search results be grouped by type (e.g. 
show all results from Using Django first, followed by all results from API 
Reference)... or whatever. Or a user could use checkboxes to select which 
section of the docs they want to search. Or faceted search results so users 
can quickly toggle or filter the sources of the search results? There are a 
lot of ways to solve this - just pointing out that our search experiences 
could be  sharper and more customizable.

2) I've encountered a number of situations where search didn't help because 
I didn't yet know enough to search for the right thing. I remember early in 
my Django experience trying to figure out how to have a "global variable" 
for my project and that search string not turning up what I needed to 
know... because what I really should have been searching for was "context 
processors".* I think we could make strides in search-ability through the 
indication of a tagging system. Tags could either be controlled through 
commits, or dynamic (users could tag topics on the fly, and a weighting 
system would apply to search results). 

* Even today, searching the docs for "context processor" does not take me 
quickly to a clean example of how to implement a context processor - I 
really have to dig for this information. 

./s

-- 
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/da7ae84d-7696-4705-b8a3-115c9ec40b94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Scot Hacker]

+1 for this change. 

This issue bites our team every time we copy a db from production to dev or 
stage or local, and certain features break because of the mis-pointed Sites 
setting.  

./s

-- 
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/903506e5-5b77-4e19-a028-3e714927b14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.