I am making an app. In which multiple superusers are there and beneath these super user we have multiple user. I am able to make superuser.But I am not able to add user in that for that super user.I am relatively new in django.
Superusers are special as their permission system returns True on every permission request (it is hardcoded). There is no "super group". You can simply create a group and give it all permissions (so add, change and delete permission to every model).
Related
In a Django Application, I have a model called application.py which is created by a user say "u". I want to list all the application created by the user "u" later, so i may need to add a reference to the model application.py from user.py.
I have one more requirement , as an admin , i need to provide access to any number of users to the same applications. So I assume this can be done with many to many relation.(Since users can access many applications).
Now the question is , is it possible to implement this behavior with user groups ,with one group is responsible for handling one application, so that in a later point of time i can add as many users as needed from the backend to respective groups to manage the same application.?
Which one is better , managing the users using many to many relation with model application.py or relating a group to application.py
and managing users using groups.
There are multiple ways to solve this, but it from a future flexibility point of view this sounds like a Role, Permission and Group relationship:
Applications have a many-to-many relationship to Users through a Membership.
Each membership would point to a Role. That could be hard-coded to start with (just a string like 'admin' or 'viewer').
This way a User can be associated to an Application as viewer or as an admin.
In the future, to add flexibility, you would have a model Role that describes the role (and could be associated to one or more Permission models to list the permissions for each role). So Membership would have a pointer to Role via a ForeignKey.
Check the documentation on extra fields on a many-to-many relationship.
There are also packages that solve this problem, e.g. django-permissions and django-role-permission
I have a 'Document' model which has many-to-many relationship with User model.There is a separate web page in my project which displays the Document instance in a text editor.
Now suppose user who created one document wants to invite other users to this document.But he wants to give read-only permission to some and read-write permission to others.
How do I implement this permission functionality in Django?How do groups and other permissions frameworks work in Django?
Django Group and Permission applies on model itself. So for a specific entry of document if you want to give access to user in that case you need to change your schema of Document model. Just add a users_who_can_read=ManyToMany(Users), users_who_can_write=ManyToMany(Users), and at your view.py when a user is trying to load a page just check if he is in users_who_can_read or not.
I think it should solve your problem without much problem.
In Django, i have extend the AdminSite class into a UserAdminSite class. But there is a problem: Any Admin who has access to the UserAdminSite would also have a "is_staff = True" status and could therefore access the default admin site for the entire website. How do I separate the access permission for these two admin sites?
Under Site Administration: Add a new "Group"; then select which permissions you want to give any user assigned to that group.
After creating the new group, then assign the user to that group.
I understand the basic user stuff. I know authentication, login, creating accounts, etc. But now I want to work on groups and permissions.
Where is the documentation for django groups/permissions? This is not it: http://docs.djangoproject.com/en/dev/topics/auth/
I suppose the first question you need to ask are what permissions do you need and what sort. By what sort, I mean do you want Model- or Object-level. To clarify the difference say you have a model Car. If you want to give permissions on all cars, then Model-level is appropriate, but if you want to give permissions on a per-car basis you want Object-level. You may need both, and this isn't a problem as we'll see.
For Model permissions, Django handles these for you... mostly. For each model Django will create permissions in the form 'appname.permissionname_modelname'. If you have an app called 'drivers' with the Car model then one permission would be 'drivers.delete_car'. The permissions that Django automatically creates will be create, change, and delete. For some strange reason they decided not to include read permissions from CRUD, you will have to do this yourself. Note that Django decided to change CRUD's 'update' to 'change' for some reason. To add more permissions to a model, say read permissions, you use the Meta class:
class Car( models.Model ):
# model stuff here
class Meta:
permissions = (
( "read_car", "Can read Car" ),
)
Note that permissions is a set of tuples, where the tuple items are the permission as described above and a description of that permission. You don't have to follow the permname_modelname convention but I usually stick with it.
Finally, to check permissions, you can use has_perm:
obj.has_perm( 'drivers.read_car' )
Where obj is either a User or Group instance. I think it is simpler to write a function for this:
def has_model_permissions( entity, model, perms, app ):
for p in perms:
if not entity.has_perm( "%s.%s_%s" % ( app, p, model.__name__ ) ):
return False
return True
Where entity is the object to check permissions on (Group or User), model is the instance of a model, perms is a list of permissions as strings to check (e.g. ['read', 'change']), and app is the application name as a string. To do the same check as has_perm above you'd call something like this:
result = has_model_permissions( myuser, mycar, ['read'], 'drivers' )
If you need to use object or row permissions (they mean the same thing), then Django can't really help you by itself. The nice thing is that you can use both model and object permissions side-by-side. If you want object permissions you'll have to either write your own (if using 1.2+) or find a project someone else has written, one I like is django-objectpermissions from washingtontimes.
I'm making a SAAS and I've been asking a slew of questions on here related to the Auth system built in. I'm having trouble understanding the "why" and "how". Primarily I don't understand how it fits in with my SAAS.
I (do) know the following:
You can do this: http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
There are many reasons to use the built in auth system (like security) instead of rolling your own
I (don't) know the following:
class MyUserProfile(models.Model):
"""
Administrator for an Account. Can edit tickets and other stuff.
"""
user = AutoOneToOneField(User, primary_key=True)
account = models.ForeignKey(Account)
dogs_name = models.CharField(max_length=255)
In the previous example, account is just what you'd expect; an entity that's paying to use my software. user is my main concern. Somebody goes to a page and creates a UserProfile with a username and password, etc. When they do this, where does the related User get created? Do I need to create it in my view manually based on the request.POST['username'], etc, and then do
myuserprof = MyUserProfile.create(user=foo_user_just_created, account=foo_account, dogs_name='Spot')
I don't know why but for some reason I feel like I'm missing something. This idea of asking somebody to sign up for an account, and then create a MyUserProfile with a form that asks for the password, username, email, et al, and then in my view creating 2 different objects (MyUserProfile and User) with different parts of the form data. I mean I shouldn't have a User form right? Like I said, I feel like I'm either skipping a step or I'm in the wrong paradigm. I'm not new to Django, but for some reason I have trouble with things that I didn't build (I think it might be a mental problem for real at this point).
Maybe there is a good example of this sort of thing being done on some open source project.
Update: Oops, forgot to mention that in the code above I tried to use AutoOneToOneField from django-annoying, but I have no idea where all the User's attributes get set or how to decide which User object to attach to it. This stuff is driving me crazy.
Also, do I need to use the sites app to do this stuff, and finally does a "super user" have all permissions to everything (I don't want people from Account "Acme" to access account "Microshaft" objects)? Or do they just have all permissions to all views?
Somebody goes to a page and creates a UserProfile with a username and password, etc.
UserProfile doesn't have an username or password field. So it should be somebody goes to a page and create an User. Then, it creates an UserProfile associated to that newly created User.
The question is, how and when do you want this UserProfile instance to be created?
Automatically, whenever a new User is created : use signals, as described in the docs
Automatically, whenever the profile is accessed from an user instance : use AutoOneToOneField, and access the profile using user.userprofile instead of user.get_profile()
Manually. But don't forget an user might have no UserProfile associated yet, so user.get_profile() might raise a DoesNotExist exception.
When they do this, where does the related User get created?
It doesn't. You have to create it explicitely.
This idea of asking somebody to sign up for an account, and then create a MyUserProfile with a form that asks for the password, username, email, et al, and then in my view creating 2 different objects (MyUserProfile and User) with different parts of the form data. I mean I shouldn't have a User form right?
Why not? You want here to create an User and his associated profile in one go, right? You could eventually use directly the POST data, or use a Form to access to the fields, or even better, use 2 ModelForm (one for User, one for UserProfile) that you will process in the same view (maybe this question can help?)
Maybe there is a good example of this sort of thing being done on some open source project.
I suggest you check out django-registration and django-profiles.
Note
You have another way of adding information to an User object, by extending the model itsel. It will allow you to put your extra fields directly in the user model and might be easier for you to understand and use.
I won't dive into details here, have a look at that tutorial for more informations.
Other questions
I tried to use AutoOneToOneField from django-annoying, but I have no idea where all the User's attributes get set or how to decide which User object to attach to it. This stuff is driving me crazy
See above on how to use it. If you feel uncomfortable with it, the best is to follow the documentation, which recommend using a ForeignKey with unique=True in user profiles.
Also, do I need to use the sites app to do this stuff
From the site framework docs : Use it if your single Django installation powers more than one site and you need to differentiate between those sites in some way.
and finally does a "super user" have all permissions to everything (I don't want people from Account "Acme" to access account "Microshaft" objects)?
Again, from the docs, Designates that this user has all permissions without explicitly assigning them. That means that everywhere Django is using the built-in permission system (e.g. default administration pages), a super-user will be authorized.
In views you're writing yourself, or if you tweak some ModelAdmin, it's up to you to decide how you are going to check permissions.