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 <scot....@gmail.com> 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.
