James,
I think the root cause of all these problems is Slide requires a user
to have read privileges on all upstream folders to enable himself to write
in a folder he has write privilege on. I think this is not a reasonable rule
and it brings out quite some problems. So I'd like to know whether you
take this as a defect and have a plan to fix it in the near future?
regards,
Jun
James Mason <[EMAIL PROTECTED]> wrote:
Gao Jun wrote:
> James,
>
> Your recommended approach means
>
> 1. each time when I created a new user, I need
> to traverse all the nodes in the tree and add "read deny" this new user to the node.
Not *every* node, since the permissions will inherit, but probably more
nodes than you want to deal with.
>
> 2. when I want to assign a folder to this user, I will go to delete all the "read
> deny"s to him in this folder's all upstream folders and all downstream folders.
Again, inheritance would make this easier.
>
> 3. each time I create a new folder, I need to add "read denys" of all the users of
> this system who shouldn't see this folder - I don't know how to retrieve this user
> list yet.
You can retrieve the list of users from the /users.
>
> What we are building is a totally dynamic system, users can keep creating new users
> and new folders, each user has his/her own accessible folders. Do you think this
> approach is a feasible one? Thanks.
Yes, this is feasible. What we've done for our setup is make two
"categories" of collections, public and private. Because our default
permissions allow read access to everything for everyone, to make a
section "private" you must explicity deny everyone access. Then you only
grant access to the users/roles that need it for that section. Because
permission inherit you only need to make the root folder a section
private and everything under that folder becomes private as well.
For what you're working on it might make sense to enforce some default
permissions. You can either do this through your UI or Content
Interceptors/Event Listeners. You should be able to set something up so
that anytime a new collection is created at a certain level it
automatically gets a permission that denys read to everyone and grants
read to the owner/someone else. That will lower your overhead for
creating new folders.
-James
>
> regards,
>
> Jun
>
>
>>Ok, I think I understand the issue a bit better now.
>>
>>What I'd recommend is you start with the largest group of users possible
>>and work your way down. Start by granting read to authenticated on A.
>>This will give all of your users read access to the entire tree, so you
>>don't need to worry about that. For special cases, such as Carl, you'll
>>need to modify the permissions further down. Grant Carl write access to
>>C1 and deny him read access to B2. The consequence of the way
>>inheritance works in Slide is that you're going to have a lot of "deny"
>>permissions to keep people out of certain areas.
>>
>>-James
>
>
>
> ---------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
