Hi, I've given a lot of thought on this, I have also searched for django apps that deal with permissions, I didn't find something that implements hierarchical object level permissions, I have a feeling that I am overcomplicating things if none did this...
Well, first of all I thought of creating a through table for the Object and user relation, so permission should have a value (how should I name this? level?) The idea is that a value of 1 means the user can read and 2 that the user can write, so to check if a user can read I can compare value>=1 In this way I can also pave the way if I want to implement revoke permission, which could be value=0 Actually the module would be the root level, so Module->project->project->project->task->task->task So a user with permissions to a project has also permissions for its subprojects and tasks. What do you mean floor? mptt seems a very nice solution but... To check an object permission I would need to get the first ascendent with permissions registered, with django-mptt I can get all ascendents, this could be a problem if the object is too deep. I then would need to loop through the ascendents and check if there are permissions registered for the current user, this would make yet another query, the permissions are on another table Also, I'm not sure how I would list the objects the user can read for example, opening an project page should list only the tasks and subprojects the user can read. Of course if I ca loop all tasks to get the ones the user can read, but this would be prohibitive slow, how can I do this with django mptt in one query? On the other hand the idea of copying the parent permission when an object is created have cheap reads, not so expensive writes but I'm afraid would make a too big permissions table (number of users X number of lines for most tables) Thanks for the considerations Avraham On Tue, Dec 13, 2016 at 3:05 PM, Vinicius Assef <vinicius...@gmail.com> wrote: > Yes, mptt can save your day. > > When handling hierarchies it's important to establish clear priorities. > > An example: given the following hierarchy: Project (1st "floor") -> Module > (2nd "floor") -> Task (3rd "floor"), if not directly assigned, a task > should consider module's permission? Or the project's permission should > always rule that situation? > > The object's "floor" is important. > > -- > Vinicius > > > On Tuesday, 13 December 2016, Avraham Serour <tovm...@gmail.com> wrote: > >> 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/ms >>> gid/django-users/CAFmXjSDOybmJ0EfBA1ECv9Mf6MFAtaEx6%2BrP8XB4 >>> x%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/ms >> gid/django-users/CAFWa6tK2UFnOwPo_6_VqZSdMnnjV8NxdVfdLsuwvM9 >> 0OQjifhQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAFWa6tK2UFnOwPo_6_VqZSdMnnjV8NxdVfdLsuwvM90OQjifhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from Gmail Mobile > > -- > 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/CAFmXjSAEJuVFmdvnqgMpMr4%2BUBCuCAzGL9X79J-FSj6zfQ1Ung% > 40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAFmXjSAEJuVFmdvnqgMpMr4%2BUBCuCAzGL9X79J-FSj6zfQ1Ung%40mail.gmail.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 https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tKW%3DOOigm81azF77W-wF1E_FQY%3D7MmH6t3YdAqjEdEC3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
