Show only users that don't yet exist in the through table - python

Inside of the __init__ method of a form ProjectUserCreateForm(forms.ModelForm) to add Users to a Project (Project model has a users = models.ManyToManyField(...)) I have
self.fields['users'].queryset = User.objects.filter(company=self.request.user.company)
This way I'm able to show only the users to be added to the Project that belong to the company of the user requesting the page.
This form can be found in
path('<int:pk>/users/create/', views.ProjectUserCreateView.as_view(), name='project-user-create'),
where the <int:pk> is the PK of the Project, and ProjectUserCreateView is a CBV CreateView.
How can I show only the users that belong to the company of the logged in user (this part already works) AND that don't yet exist in the through table (the table based on the ManyToManyField)?

You can get all users that do not yet belong to the request.user's company with:
users_in_company = request.user.company.user_set.all().values(pk).distinct()
users_not_in_company = User.objects.all().exclude(pk__in=list(users_in_company))
Bonus:
If you want to get all users which don't belong to any company:
users_not_in_any_company = users_not_in_company.filter(company__isnull=True) # Equal to User.objects.filter(company__isnull=True), but it doesn't really matter.
Note:
request.user.company.user_set.all()
If you changed the related name of the user to the company, change user_set too ofcourse. I could give you the full example code, but alas, no models.
Edit:
To get all users in a company if the request.user has one:
users = request.user.company.user_set.all()
To filter those users which belong to a specific project:
users.filter(project=my_project)
To get users that don't belong to the project:
users = User.objects.all().exclude(project__pk=self.kwargs['pk'])
To get users that belong to the request.user's company, but not to a project:
request.user.company.user_set.all().exclude(project__pk=self.kwargs['pk'])
Final
User.objects.filter(company=self.request.user.company).exclude(project_users=project_pk)

Related

Problems limiting editors to their own content in Wagtail admin

Users that have been assigned to a group with 'add' permissions are able to access, copy, move and add pages created by other users via the admin search or by directly entering the correct path in the browser.
The goal is to prevent users from seeing anything the other users are doing. I had thought it was pretty much implemented.
My page tree looks like this:
Home > Persons > Person Profile > Person Story
Users sign up for an account and are automatically assigned to a custom 'Authors' group. This group has 'add' and 'publish' permissions on the Persons page. The user is responsible for any number of people on their team. With this setup they are able to add a Profile page for each member of their team. Then multiple stories may be added for each person with a profile. Now each Person has subpages of Stories linked to their profile.
I have the page explorer set so users only see their pages:
#hooks.register('construct_explorer_page_queryset')
def show_authors_only_their_articles(parent_page, pages, request):
user_group = request.user.groups.filter(name='Authors').exists()
if user_group:
pages = pages.filter(owner=request.user)
return pages
The image chooser also only displays images uploaded by the user:
#hooks.register('construct_image_chooser_queryset')
def filter_images_by_user(images, request):
images = images.filter(uploaded_by_user=request.user)
return images
And page summary items show only what belongs to the user using similar code.
But during what I thought was going to be final testing, I discovered that a search done using the admin search leads to a list of all available Person Profile and Person Story pages with those search terms. For example if they search for 'John', all Profile and Story page are returned for John. Users may then click on John's Profile page. Once arriving on John's profile page in the explorer they are able to add Stories to John's profile, copy, move or unpublish it! They can do the same with John's stories, minus adding a subpage.
This is a game changer and won't work for us.
I've looked around and see what might be several solutions:
1) Create a similar setup using ModelAdmin but I think I'm going to have the same problem. When searching users will still be able to find and manipulate forbidden content.
2) Create a unique user group for each user as recommended in this post: Wagtail per page user permission
In the second method, after the user is created I would need to programmatically:
1) Create a new user group just for them, maybe using their username.
2) Assign them to the new user group
3) Create a new 'Person' page specific to them and grant them 'add' and 'publish' permissions to it.
The last step because it seems that if I assign them all to the same Person page, they will still be able to add pages to other users Profiles regardless of being in a different user group, since all those different user groups will still have add access to the same Person page.
Ultimately I need to block each user off from what the other users are doing. Your thoughts are much appreciated. It's been years since I've done any programming and I'm still catching up. In the meantime I'm going to start seeing I can come up with.
I think we are pretty close. The system works and flows so well!
I finally figure this one out by searching for instances of GroupPagePermission and GroupCollectionPermission in the Wagtail core package. Was able to piece it together looking at how they did it.
In the models.py of an app I have called 'users' I implemented the django-allauth user_sign_up #receiver. As soon as the user is successfully signed up it runs the below code:
from django.contrib.auth.models import Group, Permission
from django.dispatch import receiver
from allauth.account.signals import user_signed_up
from wagtail.core.models import Page, GroupPagePermission, GroupCollectionPermission, Collection
from article.models import PersonIndexPage
#receiver(user_signed_up)
def create_user_group_and_pages(sender, **kwargs):
"""
When a new user signs up create a unique group and page for them.
Assign it the appropriate permission for admin, page and collection access.
"""
# Grab the new user
user = kwargs['user']
# Create a group object that matches their username
new_group, created = Group.objects.get_or_create(name=user.username)
# Add the new group to the database
user.groups.add(new_group)
# Create new permission to access the wagtail admin
access_admin = Permission.objects.get(codename='access_admin')
# Add the permission to the group
new_group.permissions.add(access_admin)
# Now start creating page access
# First find the homepage
home = Page.objects.get(slug='home').specific
# Create unique PersonIndexPage for the user
person_index_page = PersonIndexPage(title=user.username)
# Add PersonIndexPage to homepage as a child
home.add_child(instance=person_index_page)
# Save new page as first revision
person_index_page.save_revision()
# Create new add GroupPagePermission
GroupPagePermission.objects.create(
group=new_group,
page=person_index_page,
permission_type='add'
)
# Create new GroupCollectionPermission for Profile Images collection
GroupCollectionPermission.objects.create(
group=new_group,
collection=Collection.objects.get(name='Images'),
permission=Permission.objects.get(codename='add_image')
)
Now when a creates a new account a new Index page is created for them that has a unique group created that gives them access to only that Index page and it's child pages. Effectively blocking them from access to any other content on the site. They can still see results to other pages in the admin search but don't have permission to do anything with those results.
Users can log in, create profiles for each person and then as many stories as they want for each person.

Restricting access via user email Django Saleor

I want to try setup a private website, where users can purchase bookings but only their own bookings can be viewed within the entire shop when logged in. Saleor seems to be the most complete ecommerce package for Python/Django.
Is there a way i can block access to using categories? As in, i can create a category 'Johnson Family' and only select certain users to have access to 'Johnson Family' categories, if i approve their email to have access. Then those users would then see 'products' or 'bookings' specifically for them within the shop.
Edit: Apologies, i should of ask 'how' and not 'if' of course it can be done in Django, but i wasn't sure 'how?'
As you have asked a generalized question, here is the generalized solution:
Is there a way i can block access to using categories?
Yes, you can. Django auth module has a concept of group where you can create a group and add users to this group. Then in your view you can check whether user belongs to the particular group or not. You can do something like:
from django.contrib.auth.models import User, Group
#create the group
group = Group(name='Johnson Family')
group.save()
# Add user to the group
user = User.objects.get(email='some#email.id')
user.groups.add(group)
# Call this method from your view to check if user belongs to a group
def is_member(user, group_name):
return user.groups.filter(name=group_name).exists()
Then those users would then see 'products' or 'bookings' specifically for them within the shop.
For this you can always filter the queryset to return the objects that belong to a specific user. e.g. (assuming Product and Booking model has a foreign key to user):
Product.objects.filter(user=some_user)
Booking.objects.filter(user=some_user)

User roles schema on Django

A great greetings community
My question is related with the kind of manage users and the schema users in Django, In beginning I ask to you apologize just in case that my questions can will be too "newbies" or without sense, I am starting to related me with the Django Users schemas and their different possibilities of work in the projects.
I have the following situation.
I am building an application in which I will have three differents user types:
Medical
Patient
Physiotherapist
I am using the default Django authentication scheme (django.contrib.auth).
Initially, I did think in this scheme of entities in which the User table is the auth_user table in where Django save the users created:
I have the is_patient, is_medical and is_physiotherapist fields like boolean attributes in the User table.
Like a particular detail I understand that in the Django default model User is not possible modify or add attributes or fields.
This is an important and powerful reason to I cannot add the is_patient, is_medical and is_physiotherapist boolean fields in User table.
A classic recommendation is extend the User model with a Userprofile table in which I add fields or attributes to User Model through of OneToOne relationship. A basic sample is such as follow:
Is of this way that I get that my users in Django can have the field photo and upload one in a given moment ...
Taking advantage of the previous,
The following schema can be suited or can be an alternative for manage user roles (patient, medical and physiotherapist user types) ?
I will have relationships between:
User medical and user patients
user physiotherapist and user patients
and so between them and other tables ...
With this approach these relationships don't will be affected?
The different users will be saved between the Users and UserProfile table.
Is this a good practice in the scalability sense? My tables could be crash or my database?
In addition, I also have seen other alternatives such as:
Role Table/Model
I will have a role table/model independent or separate and that this can be related with the Django User model (One User can will have many roles by example)
This approach can be useful when I want store exclusive information about of a role in specia?
Django Permissions and Authorization
I ignore or unknown the granularity grade that let will me work. Of a single way I have been see that the permissions and authorizations system let will me work with create and edit and remove operations ....
Here, can I see the groups creation?
For example a medical group and allocate them permissions and linked this permissions to the users that compose the group ? Is this another good alternative?
This option seem more single although I don't know if an user could make some operations according to the group privileges that have ... I don't know if this thinking is correct/right
AUTH_USER_MODEL Creating a Custom User model
My requirements for patient, medical and physiotherapist users, require build a custom user model?
In this situation, especially if you want to store different infos for Patients, Medics and Physiotherapists you can create a Model for each and have a OneToOne field for each to the User model.
class Medic(models.Model):
user = models.OneToOneField(User, primary_key=True)
# other fields
class Physio(models.Model):
user = models.OneToOneField(User, primary_key=True)
# other fields
class Patient(models.Model):
user = models.OneToOneField(User, primary_key=True)
# other fields
This way you can give different permissions/roles implicitly in your application logic for each type of user (and still use the groups and permissions that Django offers if you need them for special cases, eg ChiefMedical...).
You will have to define some methods for your application logic like
def user_is_patient(user):
...
If you follow this path it is a good idea to have good tests to make sure that you don't get unexpected things like a user who is a Medic and a Physio...
Django lets you subclass the user model as well. Under the covers it would do the same thing as the code above, so it is probably better to do it explicitly as shown above (this way it is less probable that you access attributes that don't exist in that object!)
Taking advantage of the previous, The following schema can be suited or can be an alternative for manage user roles (patient, medical and physiotherapist user types) ?
The schema you show isn't great because it makes you store the information for all user types in the same table (and with the same fields). For example, Medics and Physios will have a blood type field type like Patients which will probably not be defined.
The different users will be saved between the Users and UserProfile table. Is this a good practice in the scalability sense? My tables could be crash or my database?
There should be no scalability problems with this solution (as long as you don't have millions new entries writes every day) and you can always optimise the database at a further point. However, you will have to make sure that your app doesn't accept 'forbidden' entries (e.g. users with no Medic, Physio or Patient profile)
Here, can I see the groups creation? For example a medical group and allocate them permissions and linked this permissions to the users that compose the group ? Is this another good alternative? This option seem more single although I don't know if an user could make some operations according to the group privileges that have ... I don't know if this thinking is correct/right
You can (should) use Django's permission system to give permissions to your users. You can use them to give different rights to users of the same type (for example Medics that have more permissions than others... or have groups for chief physios...)
Django lets you assign permissions to a group.
But I don't think groups can replace the custom models for each user, since you want to store information for them. Having custom models and groups would be redundant and make your app harder to maintain.
My requirements for patient, medical and physiotherapist users, require build a custom user model?
This option wouldn't be great (unless it is your only option) because your app won't be reusable and you might have problems with some packages as well.
You can create a custom User model or not, in any case, you could have three separate models for storing pertinent data, depending on whether the user is patient, medical, physiotherapist, or any combination of these.
If your permissions scheme is determined solely by the role (patient, medical, physiotherapist) then you don't need to use Django's permissions system, because you know the role(s) of any user and you can, in the worst scenario, hardcode authorization rules.
I gave a glance at question's comments and I view some issues:
()
I realized that your user model does not match with the original data model since having get_medical_profile, get_patient_profile and get_physiotherapist_profile functions inside user model, with that you are assuming that any user could have multiple profiles at the same time, which isn't reflected neither in your profile models (Medical, Patient and Physiotherapist) using OneToOneField nor in original data model of the question, it's an important thing about abstraction and class-responsibility. The requirement (according the model below) seems to say "one user can have only one profile".
So.. I think this can be solved in a straightforward and clean way, you don't need to involve in overall authentication esquema like groups and permissions or adding additional attributes to user model:
class UserProfile(models.Model):
user = models.OneToOneField(User)
# common fields shared by medical, patient and physiotherapist profiles
class MedicalUser(models.Model):
profile = models.OneToOneField(UserProfile)
# medical fields here
class PatientUser(models.Model):
profile = models.OneToOneField(UserProfile)
# patient fields here
class PhysiotherapistUser(models.Model):
profile = models.ForeignKey(UserProfile)
# patient fields here
As you see, you can have a profile which contains common fields shared by all profiles. and each profile has an specific model.
In addition, you can check if user is medical by this small function below, then if there is no an medical profile associated with profile then it will raise exception and it means it's a profile unspecified:
def is_medical_profile(profile):
try:
profile.medical_user
return True
except:
return False
You can also use it in your templates (as a custom template tag) in this way:
{% if profile | is_medical_profile %}
With this approach you don't need to setup AUTH_USER_MODEL
I hope this improves your solution.
Additional notes:
Just in case you decide to have a custom user model, setup settings.AUTH_USER_MODEL and use it for foreign keys to User.
On a piece of text of awesome book Two scoops of Django says:
From Django 1.5 onwards, the official preferred way to attach
ForeignKey, OneToOneField, or ManyToManyField to User
Therefore, your user profile model would change as follows:
from django.conf import settings
from django.db import models
class UserProfile(models.Model):
user = models.OneToOneField(settings.AUTH_USER_MODEL)
Yes, it looks a bit strange, but that's what the official Django docs advice.
#geoom #Ire #lorenzo-peña I 've created an user through Django admin site and I checked their attributes (is_medical, is_patient, is_physiotherapist) via python shell
In [6]: User.objects.filter(username='agarcial').values('is_medical','is_patient','is_physiotherapist')
Out[6]: [{'is_physiotherapist': True, 'is_patient': True, 'is_medical': True}]
For the moment in my views.py I am doing that an user sign in only when this be one of three user types (medical, patient or physiotherapist)
# Create your views here.
class ProfileView(LoginRequiredMixin, TemplateView):
template_name = 'profile.html'
def get_context_data(self, **kwargs):
self.request.session['Hi'] = True
context = super(ProfileView, self).get_context_data(**kwargs)
is_auth = False
name = None
# Check if in the request goes the user
user = self.request.user
# Check about of possible cases (For now is one profile)
if user.is_medical:
#if self.request.user.is_authenticated():
print (user.is_medical)
is_auth = True
profile=user.get_medical_profile()
#name = self.request.user.username
data = {
'is_auth':is_auth,
'profile':profile,
}
context.update({'userprofile':profile, 'data':data})
elif user.is_patient:
print (user.is_patient)
is_auth=True
profile=user.get_patient_profile()
data = {
'is_auth':is_auth,
'profile':profile,
}
context.update({'userprofile':profile,'data':data})
elif user.is_physiotherapist:
print (user.is_physiotherapist)
is_auth=True
profile=user.get_physiotherapist_profile()
data = {
'is_auth':is_auth,
'profile':profile,
}
context.update({'userprofile':profile,'data':data})
return context
def get_userprofile(self):
return self.request.user.userprofile
If I check the other possible combinations (User patient,medical and physiotherapist) this could work?
I think create groups for (Medicals, Patients, Physiotherapists) and binding users for the authorization topic, although I should review other things for authorization process such as django guardian for example?
How about this?

Django: Including standard User table as foreign key in my models?

I am designing a Django 1.8 application in which I have the concept of trials and assessors. I will have six assessors, who will use the Django admin to log in and make assessments.
I want each trial to have two attached assessors. How can I use the Django User model in models.py to ensure that the assessors are Users, and can be managed using the full power of Users?
Right now I have this, in which the assessors are not Users, but are just ordinary models:
class Assessor(models.Model):
name = models.CharField(max_length=200)
class Trial(models.Model):
title = models.CharField(max_length=800)
publication_date = models.DateField()
first_assessor = models.ForeignKey(assessor)
second_assessor = models.ForeignKey(assessor)
I want the assessors to be Users, so that I can manage them in the usual way through the User tables, but I don't know how to make this change.
They probably don't need any custom fields on top of the standard User attributes.
(NB: I don't need full-on permissions management within the admin, it's OK for any assessor to be able to edit the trial.)
UPDATE: Apologies, this is rather hard to explain! I don't care about the Django front-end at all, only the admin. I want a user to be able to log into the admin, see all the trials on which they are a primary assessor, and edit those trials. I'm not sure if it's best to do this with the User model, or not.
Instead of two foreign keys add a manytomany relation from Trail to user. Later, if you want you can add more assessors to a trail.
You can do like:
from django.contrib.auth.models import User
class Trial(models.Model):
title = models.CharField(max_length=800)
publication_date = models.DateField()
assessors = models.ManyToManyField(User,related_name="trials")
You can add assessors to Trial like:
trial = Trial.objects.get(id=give-trial-id)
user = User.objects.get(id=give-assessor-id)
trail.assessors.add(user)
You can get more info about manytomany here
I just saw your UPDATE. Any one who logs in to admin will have access to all objects of all models.
In your case all assessors who login to admin will have access to all trails irrespective of they are assigned to it or not.
If you want Filter django admin by logged in user then refer this question

Referencing Django login name from within a model

I'll start by saying that my database skills are weak, and it's quite possible I'm just designing this wrong.
I'm working on a Django 1.3 application that would allow customers to log in to view various aspects of their "account". One of the models is "Customer", and it makes sense to me that I add a field in that model for "username" so that I can show projects, payments etc that belong to each customer.
I've got much of my schema set up but I can't figure out how to make a "username" field that references the django login name. You average field looks something like
projects = models.ManyToManyField('Project')
website = models.URLField()
updates to clarify
what I think I need is:
username = models.ForeignKey(WhereverDjangoKeepsTheUserModel)
SOLVED
I needed
from django.contrib.auth.models import User
and
username = models.ForeignKey(User)
Accepting Jack M's answer because it helped me find the specific piece I needed.
You are probably looking for a ForeignKey relationship.
projects = models.ManyToManyField('Project')
website = models.URLField()
user = models.ForeignKey('User')
Then from within your view:
project = Project.objects.all()[0]
username = project.user.username ## Or whatever you want to do with it.
To read more about this, check out the "Your First Model" section in chapter 5 of The Django Book.

Categories

Resources