Hi, Thanks for taking your time on this.
> Could a child object have a different permission from its parent? Yes, I'm thinking someone may have access to the parent but not to all childs, or read access to the project and write access to some tasks (probably the ones I'm responsible) So each object has > If it doesn't override the parent permission, you should check the parent's permission, additionally. Well, I see two problems here. 1 - Currently the system stores only who has access, a lack of it means the user has no permission. Not so big of a problem, I can change this, so it is a minor problem. 2 - I don't know the depth level, a task for example may have subtasks, which are task objects itself, which may each have subtasks and so on I would need to check each in a loop, can't do it in one query. I'm now thinking that I could use a mptt for this or maybe this would be too complicated? Using mptt I could have hierarchical permissions and check for permissions on an object and each parent if permissions are not defined, but I would need to change the way permissions are stored right now to also store negative permissions Avraham On Tue, Dec 13, 2016 at 3:34 AM, Vinicius Assef <vinicius...@gmail.com> wrote: > Considerations follow inline... > > On 11 December 2016 at 03:34, Avraham Serour <tovm...@gmail.com> wrote: > > ... > > > > So should I check the parent object permissions? or just checking the > > current object is enough? > > It depends on the granularity level of your permissions. > > Could a child object have a different permission from its parent? If > yes, you only need to check the object itself. If it doesn't override > the parent permission, you should check the parent's permission, > additionally. > > Or must it always obey the parent permissions? If that's the case, you > only need to check the parent permission. > > > > > I'm thinking of copying the parent permissions when an object is > created, in > > this way creating an object could be expensive and the permissions table > may > > get too big, but reading the permissions can be cheap. > > Or children objects can simply point to the parent to check its permission. > > You could have a column called `parent_id` in each object. If it is > the higher level, it will point to nobody (or to itself. It will > depend on your logic). So, each child will point to the parent. > Permissions must be checked using `parent_id` for relationship. > > But, again, it will depend on the granularity of your permissions and > how much you want to allow or forbid a child override a parent > permission. > > -- > Vinicius Assef > > -- > 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 https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/CAFmXjSDOybmJ0EfBA1ECv9Mf6MFAt > aEx6%2BrP8XB4x%3D%2BHsOK21Q%40mail.gmail.com. > 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 https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tK2UFnOwPo_6_VqZSdMnnjV8NxdVfdLsuwvM90OQjifhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
