the user type. It will work.
>
> I hope it helps :)
>
> Cheers!
>
>
> On Monday, June 3, 2019 at 4:04:53 PM UTC+5:30, Harsh Gundecha wrote:
>>
>> what is recommended practice for serving same object to multiple types of
>> users with slight change in output
the user type after
perform_update() was called.
And return a different response by checking the user type. It will work.
I hope it helps :)
Cheers!
On Monday, June 3, 2019 at 4:04:53 PM UTC+5:30, Harsh Gundecha wrote:
>
> what is recommended practice for serving same object to multiple types of
what is recommended practice for serving same object to multiple types of
users with slight change in output
for e.g book object or issued book object to lets say staff and students,
is it a good idea to use same URL for both and serve by checking user type
PS: its a JSON based rest API in rest
t;
> >
> > class Student(models.Model):
> > user = models.OneToOneField(User, on_delete=models.CASCADE)
> >
> > class Teacher(models.Model):
> > user = models.OneToOneField(User, on_delete=models.CASCADE)
> >
> > class Parent
filled in while Student
>> must have "date_enrolled". Similarly, you can use group membership to
>> determine what information to show.
>> Splitting them out in different profiles is a matter of preference and
>> optimization, not of design.
>>
>> > The
determine what information to show.
> Splitting them out in different profiles is a matter of preference and
> optimization, not of design.
>
> > The docs mention using a django.db.models.signals.post_save
> > <https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.mo
ect.com/en/1.10/ref/signals/#django.db.models.
> signals.post_save> signal on User, but I'm guessing that won't work
> here if you have multiple types of users.
When you have multiple *profiles* this will work just fine. It's also
not a big problem to solve, because user
t;
signal on User, but I'm guessing that won't work here if you have
multiple types of users.
Or are you better off subclassing
django.contrib.auth.models.AbstractUser? (I get the impression using
profile models is less invasive).
Regards,
Victor
--
You received this message because you
dels.signals.post_save
<https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models.signals.post_save>
signal on User, but I'm guessing that won't work here if you have multiple
types of users.
Or are you better off subclassing django.contrib.auth.models.AbstractUser?
(I get the im
Any reply yet?
I also looked at the profile functionality from auth. Seems that I can
only define a single profile for each user. What if I need to have
different profiles for different users?
On Oct 25, 1:25 am, itsnotvalid <[EMAIL PROTECTED]> wrote:
> Is there any posts related to the permissio
Is there any posts related to the permission system? I didn't looked
into that part yet, but seems interesting. Of course groups also seems
to solve the problem as well.
However I also saw @user_passes_test in the doc. What is the
difference or use cases from @user_passes_test and
@permission_req
perhaps when you create-save the models (Providers, Customers etc.) it adds
that User to the appropriate group.
but I'm not sure I would use groups. That would make the most sense if
there were people with overlapping roles. somebody who is Agent + Provider
you could use the permissions system.
Well, django user auth has groups implemented.
"It handles user accounts, groups, permissions and cookie-based user
sessions." (http://docs.djangoproject.com/en/dev/topics/auth/?
from=olddocs)
How can you effectively separate their views. Separate your apps based
on their nature, not based on wh
I am going to help some people making a website that has a few admins,
a crowd of service providers (individuals) and customers. There could
be agents who invites people to become service providers or customers
as well.
Looking at the user system provided by django, and as a new programmer
to dja
On 30-Mar-07, at 8:45 PM, johncock wrote:
> We need multiple types of users. Different profiles and different
> permission.
this has been repeatedly discussed. The auth.user model gives the
bare essentials. extending this is up to the individual developer. O
course, until model inher
Hi there,
I'm evaluating Django for a project and the framework fits in many
ways.
However on one issue it would be nice with some help to hand-sew the
glove:
We need multiple types of users. Different profiles and different
permission.
To be more specific: it is a event site where diff
On 3/26/07, Anton Stonor <[EMAIL PROTECTED]> wrote:
>
> It would be nice if I could model these use types as different user
> models, but a hack could of cause be to have one large profile and hide
> different fields according to the user type.
>
> Ideas are welcome.
Hi Anton,
James Bennett has
Hi there,
I'm evaluating Django for a project and the framework fits in many ways.
However on one issue it would be nice with some help to hand-sew the glove:
We need multiple types of users. Different profiles and different
permission.
To be more specific: it is a event site where diff
18 matches
Mail list logo
