Hello everyone!
I was advised to open a new topic here for further discussions.
My goal is to move this ticket from Someday/Maybe to Accepted.
Description
contrib.auth’s Group model is not customizable at the moment, users have to hack around Django to customize it: How do I extend the Django Group model?.
The customization of the Group model is necessary in any bigger project, and defining a secondary model - which is the recommended way to attach fields to the Group model - doesn’t always cut it. It’s impossible to “nest” groups via a secondary model, for example.
To solve this, I suggest making the Group model swappable with the AUTH_GROUP_MODEL setting. It’s consistent with the User model, and it would solve the customization issues.
WDYT?
Links
Hi @csirmazbendeguz — I’d need to compose my thoughts more completely here but, I think, whilst swappable models are great in the right places — Waffle flag models being the best example in the wild, I think — they’d introduce more complexity than they’re worth here.
If a One To One field is not sufficient, I’d suggest you’re better starting from scratch with your own model — there’s very little of Django that wires into the existing one.
(In theory a more powerful roles-based permission system in Django would be nice to have. I don’t see that as realistic though.)
HTH
Just ref the ticket, I’d probably say it should be closed as wontfix.
Yes, my issue with the OneToOne field solution is, it’s not always sufficient.
It’s also a compromise on database design - it would make sense to store extra fields (e.g. a description field) in the Group’s table, instead of a separate table.
If there’s very little code that uses the Group model, is it really that complex to make it swappable? The need for customizing the Group model will always be there, if Django won’t support this, users will keep hacking around Django - but as far as I understand you’re saying that’s preferrable? In that case yes, we should probably close it as wontfix.
Yes, I get the limitations…
I think there’s little benefit to making the Group model swappable. I think in contrast it adds a new setting, and quite a lot of documentation, which users need to understand, and crucially do so at a very early stage in their Django journey (since swappable models generally need to be set before the first migration). That then leaks into arguments for making the project start template more complex. And so on.
Having a swappable model here also has an effect of guiding folks towards the thought that maybe it’s a good idea to swap it. That they SHOULD be using one. I think that’s often not true (rarely true?) but why would the knob be there if you weren’t meant to turn it?
I understand there’s always trade offs, and there are arguments for thinking otherwise, but I lean the way I do for roughly these reasons.
1 Like
Thanks @carltongibson, fair enough, I suppose we can wait for others to share their thoughts as well and let’s close the ticket after a reasonable time frame - let’s say 2 weeks.
BLF: I agree with Carlton.
Just to offer a different perspective, opinionated and not authoritative, we have a project where we needed a custom Group-like model to support a row-level security model.
Our solution was to ignore the existing Group model completely, and implement our own. The basic implementation turned out to be not very difficult. (The real logic behind the use of Group for authorization is performed in the UserManager and PermissionMixin classes - which in a custom authorization situation would need to be overridden anyway.)
So in the case where you need a more sophisticated Group-ish model, I’m not seeing the benefit of overriding the existing model as opposed to just creating your own.
Side note: If your only need is for a hierarchical structure for Group, I’d actually suggest an external model implementing a materialized path tree with a ForeignKey to the Group model.
Thank you @csirmazbendeguz for creating this post and doing the proper follow up to this topic. I read the django-developers thread and this post, and I also reviewed your PR.
While your PR is clean and addresses the goal in a concrete and consistent manner, the overall feedback about the challenges and complexities for having another swappable model for Group makes me lean towards the “let’s not do this” vote. My main reason is that the impact on third party apps is big, we are still seeing the fallback of needing AUTH_USER_MODEL being properly used in apps and I think the cost of this change is too high for the benefits it provides (also considering the suggested workarounds).
1 Like