# Custom Group model **URL:** \ **Category:** Django Internals\ **Created:** [April 11, 2024, 10:57am UTC](https://forum.djangoproject.com/t/custom-group-model/30070 "2024-04-11T10:57:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![csirmazbendeguz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/csirmazbendeguz/32/19797_2.png) [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)\ **Post date:** [April 11, 2024, 10:57am UTC](https://forum.djangoproject.com/t/custom-group-model/30070/1 "2024-04-11T10:57:08Z")
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?](https://stackoverflow.com/questions/2181039/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** - [django-developers](https://groups.google.com/g/django-developers/c/llQJZUKejXg) - [PR](https://github.com/django/django/pull/18053) - [ticket-29748](https://code.djangoproject.com/ticket/29748) ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [April 11, 2024, 12:04pm UTC](https://forum.djangoproject.com/t/custom-group-model/30070/2 "2024-04-11T12:04:51Z")
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`. ---
**Author:** ![csirmazbendeguz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/csirmazbendeguz/32/19797_2.png) [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)\ **Post date:** [April 12, 2024, 1:38am UTC](https://forum.djangoproject.com/t/custom-group-model/30070/3 "2024-04-12T01:38:40Z")
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`. ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [April 12, 2024, 5:13am UTC](https://forum.djangoproject.com/t/custom-group-model/30070/4 "2024-04-12T05:13:28Z")
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. ---
**Author:** ![csirmazbendeguz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/csirmazbendeguz/32/19797_2.png) [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)\ **Post date:** [April 12, 2024, 6:36am UTC](https://forum.djangoproject.com/t/custom-group-model/30070/5 "2024-04-12T06:36:41Z")
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. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [April 12, 2024, 12:00pm UTC](https://forum.djangoproject.com/t/custom-group-model/30070/6 "2024-04-12T12:00:15Z")
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. ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [April 12, 2024, 8:37pm UTC](https://forum.djangoproject.com/t/custom-group-model/30070/7 "2024-04-12T20:37:07Z")
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).