Oh, my apologies, the proper argument to set the name of the table that is created for a ManyToManyField is db_table instead of db_column (which just controls the column on the user table itself). Entirely my mistake.
Best, Alex Ogier On Thu, Nov 8, 2012 at 8:10 PM, Christian Jensen <[email protected]>wrote: > Yea, the column name was the first thing I tried - it had no effect on the > name of the database table that was created. > > I am good with copying the entire ModelBackend I just thought someone > would either want to document this fact or make it configurable. > > Christian > > > On Thu, Nov 8, 2012 at 1:22 PM, Alex Ogier <[email protected]> wrote: > >> Django's permission system does expect there to be a user_permissions >> property on user objects. It's possible to change django to refer to that >> field indirectly, in the same way that it refers to >> CustomUser.USERNAME_FIELD, but Django core developers would be unlikely to >> accept the change because this is a rare use case. Instead, if you want to >> clean up the database field names, I would try adding a >> db_column="permissions" argument to the user_permissions field declaration >> in your custom user model. That should change the database field name >> without interfering with Django's ModelBackend. >> >> Best, >> Alex Ogier >> >> >> On Thu, Nov 8, 2012 at 3:27 PM, Christian Jensen <[email protected] >> > wrote: >> >>> I was tweaking around with making an email address only User model (sans >>> username) while still retaining the permissions stuff and ran into a small >>> issue. I can fix it but it might need to be documented. >>> >>> Here is the problem: >>> >>> I copied over the entire AbstractUser of django.contrib.auth.models.py, >>> made my changes I needed and just for fun changed 'user_permissions' to >>> just 'permissions' because I liked the name in the database to be >>> 'account_user_permissions' instead of 'account_user_user_permissions' >>> >>> When I went to run it, line 44 of ModelBackend died because there is a >>> hard reference to 'user_permissions' in the line: >>> >>> user_obj._perm_cache = set(["%s.%s" % (p.content_type.app_label, >>> p.codename) for p in user_obj.*user_permissions*.select_related()]) >>> >>> The only fix I could come up with quickly was to copy out the entire >>> ModelBackend and fix it there. I am probably an idiot and just not know the >>> better way to fix this. >>> >>> >>> Christian >>> -- >>> >>> *Christian Jensen* >>> 724 Ioco Rd >>> Port Moody, BC V3H 2W8 >>> +1 (778) 996-4283 >>> [email protected] >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > > > -- > > *Christian Jensen* > 724 Ioco Rd > Port Moody, BC V3H 2W8 > +1 (778) 996-4283 > [email protected] > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
