Django has foundation for object level (row level) perms:
https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#handling-object-permissions
So basically you just check:
current_user.has_perm('permname', obj)
For a full list of methods you can check:
https://docs.djangoproject.com/en/1.8/ref/contrib/auth/#methods
On 05.11.2015 12:35, Steve West wrote:
Hi all
I'm implementing a Django project in which individual table rows are
marked as either private or public. I need to be able to filter
accesses to the tables in such a way that logged-in users can see
everything, but other users only get visibility of the 'public' rows.
My initial thoughts were that I could apply a check on whether the
user is logged in in any of three places: at the model level, in views
or in templates. It seemed to me that the most elegant and robust
option would be to do so at the model level, by writing custom
managers for my models. Within the custom managers, I could check if
the user is logged in and filter all queries accordingly.
I did an initial implementation of the above approach, but quickly
found problems. Whenever I span foreign key relationships in my views,
the default model manager is invoked, so i have had to add in further
tests for whether the user is logged in at the view level. I've also
got some cases where foreign keys are spanned at the template level
and have had to add further login tests there, too.
All-in-all, I don't think I am going about this in the right way! In
the Django documentation, it seems to be mostly expected that one will
use authentication to control access to individual views or model
operations, rather than controlling finer-grained access to individual
rows, so I haven't found anything that really helps.
Can anyone please offer any advice or suggest what would be the best
way of solving the problem or point my at any documentation that might
help.
Many thanks
Steve
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/002471e1-8a64-4637-9d00-ae774924fd84%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/002471e1-8a64-4637-9d00-ae774924fd84%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/563B414A.70404%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
