I am using Zope 2.5.1, and writing a product with a folderish class. I want to be able to prevent acquiring a permission from one role, while still acquiring it from another role (if the user gets that role locally). I suppose it could work by preventing the user from acquiring a role; is there already some sensible way of doing that? It seems like the concept of assigning a permission or role to a user at an object but not at any of its contained objects would be generally useful.
John K. Hohm wrote:
It seems like the concept of assigning a permission or role to a user at an object but not at any of its contained objects would be generally useful.
You can never assign a permission to a user, only to a role. What you're after, if I understand correctly, is what's called local roles blacklisting, which is in Zope 3, again, if I understand correctly... cheers, Chris
On Wednesday 18 Sep 2002 4:00 am, John K. Hohm wrote:
I am using Zope 2.5.1, and writing a product with a folderish class. I want to be able to prevent acquiring a permission from one role, while still acquiring it from another role (if the user gets that role locally).
I suppose it could work by preventing the user from acquiring a role; is there already some sensible way of doing that?
It sound like you are trying to abuse a standard permission. Is the problem something like: your folderish product uses properties to control its behaviour, but you dont want to let some users control properties of all sub-objects? Perhaps a better way would be to define a new permission, call it "Change MyFolderishThing Properies", and leave the permission acquisition system to work as normal.
Quoting Toby Dickenson <tdickenson@geminidataloggers.com>:
On Wednesday 18 Sep 2002 4:00 am, John K. Hohm wrote:
I am using Zope 2.5.1, and writing a product with a folderish class. I want to be able to prevent acquiring a permission from one role, while still acquiring it from another role (if the user gets that role locally).
I suppose it could work by preventing the user from acquiring a role; is there already some sensible way of doing that?
It sound like you are trying to abuse a standard permission. Is the problem something like: your folderish product uses properties to control its behaviour, but you dont want to let some users control properties of all sub-objects?
No, that's not it at all. I want all authenticated users to have permissions to list the contents of the /auto folder, but I want a user to have permissions to the /auto/foo, /auto/bar, etc. folders and their contained items only if they have a role local to one of those folders. As it happens I am assigning the local roles with a BasicUser modification by virtue of a user having a role whose name is related to the name of the folder, say foo_dogs or bar_dogs.
Perhaps a better way would be to define a new permission, call it "Change MyFolderishThing Properies", and leave the permission acquisition system to work as normal.
I want the standard permissions to work normally within one folder, but I want to avoid standard permissions being used to do standard things with standard objects contained by folders beneath that folder, unless those folders have local roles that re-grant the standard permissions.
On Thursday 19 Sep 2002 1:05 am, John K. Hohm wrote:
Quoting Toby Dickenson <tdickenson@geminidataloggers.com>:
On Wednesday 18 Sep 2002 4:00 am, John K. Hohm wrote:
I am using Zope 2.5.1, and writing a product with a folderish class. I want to be able to prevent acquiring a permission from one role, while still acquiring it from another role (if the user gets that role locally).
I suppose it could work by preventing the user from acquiring a role; is there already some sensible way of doing that?
It sound like you are trying to abuse a standard permission. Is the problem something like: your folderish product uses properties to control its behaviour, but you dont want to let some users control properties of all sub-objects?
No, that's not it at all. I want all authenticated users to have permissions to list the contents of the /auto folder, but I want a user to have permissions to the /auto/foo, /auto/bar, etc. folders and their contained items only if they have a role local to one of those folders.
From what I can see thats exactly the same as my example, assuming the top level folder is your new folderish product. I suggest you create a new "list contents of top-level folder" permission, change your folderish product so that this permission controls the relevant methods, then grant this permission to everyone.
As it happens I am assigning the local roles with a BasicUser modification by virtue of a user having a role whose name is related to the name of the folder, say foo_dogs or bar_dogs.
Thats cool.
Perhaps a better way would be to define a new permission, call it "Change MyFolderishThing Properies", and leave the permission acquisition system to work as normal.
I want the standard permissions to work normally within one folder, but I want to avoid standard permissions being used to do standard things with standard objects contained by folders beneath that folder, unless those folders have local roles that re-grant the standard permissions.
Why is it critical to use the standard permission on that top level folder?
Quoting Toby Dickenson <tdickenson@geminidataloggers.com>:
On Thursday 19 Sep 2002 1:05 am, John K. Hohm wrote:
[snip]
No, that's not it at all. I want all authenticated users to have permissions to list the contents of the /auto folder, but I want a user to have permissions to the /auto/foo, /auto/bar, etc. folders and their contained items only if they have a role local to one of those folders.
From what I can see thats exactly the same as my example, assuming the top level folder is your new folderish product.
I suggest you create a new "list contents of top-level folder" permission, change your folderish product so that this permission controls the relevant methods, then grant this permission to everyone.
Although your assumption is wrong, your suggestion is excellent. :-) My folderish product is actually the sub-folder foo in /auto/foo.
As it happens I am assigning the local roles with a BasicUser modification by virtue of a user having a role whose name is related to the name of the folder, say foo_dogs or bar_dogs.
Thats cool.
Thanks, I think so, especially when following your suggestion. Creating a 'View MyProduct' permission and using declareObjectProtected lets me do what I want. Now I have the dogs role defined at /auto and assigned the 'View MyProduct' permission, but don't otherwise change the /auto permissions. The result is that only the users that get the 'dogs' role in the context of /auto/foo can see /auto/foo or anything in it, but once they have that role they can do everything with it and its contents based on what roles they have in /auto. Thanks for sticking with me on this one; it took a while for the proverbial light bulb over my head to flicker on.
participants (3)
-
Chris Withers -
John K. Hohm -
Toby Dickenson