PageUser and custom user models in Django 1.5

[Michael P. Jung (Terreon)]

In Django 1.5 it is possible to swap out the user model via
`settings.AUTH_USER_MODEL`. I was looking into making Django CMS aware
of this and found a `PageUser` class which extends the `User` class.

Now things get ugly: It should be possible to extend
`django.contrib.auth.get_user_model()` by connecting to the
class_prepared signal, but this is going to get really ugly. A better
attempt would be to extend the `AbstractUser` instead so the PageUser is
independent of the Django User.

I'm still wondering what the PageUser is good for. There are no models
with ForeignKeys to it and it seams to be dead code. If this holds true
would it do any harm to remove the PageUser?

Is there any good reason for having this model around? I tried hard to
grep through the code and the documentation and found nothing.


Michael P. Jung (bikeshedder)

--
http://terreon.de/

[Jonas Obrist]

From our discussion on IRC and some grepping, the PageUser (and probably PageGroup) model is utterly useless. 

If we can find a way to migrate away from it that is backwards compatible, i'm all for it!

[Michael P. Jung]

First of I need to find out what PageUser is really used for. It looks like it is only there to provide a simpler admin interface for the user model. This could easily be done by writing a new ModelAdmin for the original User model. There is no need for a separate PageUser model that keeps the django User in sync.

If this really is the entire meaning of PageUser, the migration should be as simple as removing the PageUser alltogether and replacing the admin stuff by a modified ModelAdmin with a custom crafted form.

If there is no other meaning to PageUser I'll prepare a patch that removes this class while adding support for custom user models at the same time. Once the PageUser is gone adding support for swappable user models in Django 1.5 becomes almost a no brainer.

[kux]

Hi all,

Copy pasting the same answer from django-cms users group :)

I went to the same thought process a couple of months ago when I first bumped into the PageUser model.

PageUser does have a self pointing foreign key called created_by which is used for creating user hierarchies.

These hierarchies are used for for users with 'can change permissions' rights.

Basically, users that are able change other users' permissions  can only do so for users below them, but not for users above.

Regards,

Alex

[kux]

docstring for cms.utils.permissions.get_subordinate_users seems to provide a pretty good explanation of why this model is used.

On Thursday, March 28, 2013 3:01:57 PM UTC+2, Michael P. Jung wrote:

[Michael P. Jung]

Oh my, this is crazy stuff and feels so wrong.

I don't even think that this works correctly. There is a PagePermission object but I found no way to manage it via the Admin UI. A newly created PageUser is kinda crippled and doesn't really work.

I think there is a design decision needed: How is this supposed to work?

[kux]

You can manage PagePermission objects from the admin of Page objects. Alternatively you can use global page permissions.

If you set CMS_PERMISSION you will have two additional InlineAdmins for managing permissions on each page (one for view permissions and one for page permissions)

For a new user to 'work', he needs to have permissions for at least one page on at least one site or give him 'global page permissions' on at least one site.

Try reading the docs on http://docs.django-cms.org/en/2.3.5/advanced/permissions_reference.html

I agree with you... It's an overly complex mechanism which takes a while to understand and which can cause quite a lot of trouble (I think I raised at least 5 issues while trying to understand how permissions work and while writing the above docs).

Probably someone from the core django-cms team can provide more insight on the requirements they had when they first implemented permissions.

But mind that as crippled as they seem, permissions DO work. I'm currently using them to administer a django-cms installation with dozens of sites and hundreds of staff users. 

Regards,

Alex

[Patrick Lauber]

Here comes the light :)

The requirements we had was:

A user has permission for pages. If he had additionally the rights to create users he only could give those new users the rights he already had or less for the pages. I think this is why there is this created_by flag so we could create a hierarchy of users.

i hope this helps…

cheers

Pat

> --
> You received this message because you are subscribed to the Google Groups "django-cms-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-devel...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jonas Obrist]

So since this seems to be only used internally in perms checks (in the admin?), how about creating a new model UserCreationLog (please rename this to something useful) that keeps track of who created who? And kill PageUser.

On Thursday, March 28, 2013 10:01:57 PM UTC+9, Michael P. Jung wrote:

[Michael P. Jung]

Thats exactly what I'm trying to do. I called the models UserCreatedBy and GroupCreatedBy and have Proxy models for User and Group that provide a created_by propery so the code using the created_by field should behave the same unless the fields are used in a query.

As the queries are kinda complex would it be an acceptable attempt to limit the maximum depth of user creation? If we limit the depth it would be simple to do a 'created_by=user' OR 'created_by__created_by=user' ... OR ...'created_by__created_by__...__created_by=user' query. I would then add a 'depth' property to the CreatedBy models which can be used to make sure that the maximum depth is never exceeded. That CMS_MAX_USER_DEPTH could even be configured via the settings so arbitary complex user hierarchies are still be possible.

Another point is regarding the deletion of users. What should happen if a user is deleted that created other users? Should it also delete the users that are now left over without a creator?

[Jonas Obrist]

I don't understand why this needs a new setting when the old code doesn't. Really adding a new setting raises a NO flag in my head...

[Ioan Alexandru Cucu]

Or you could use django-mptt (which should perform well regardless of the hierarchy's depth).

[Rob Slotboom]

Hi Jonas,

Any idea when this will happen?