After talking with a colleague it appears that you can indeed not
"take away" permissions in a subfolder, all permissions are inherited.
You could still use the scheme I outlined below by having the root
folder '/' restricted and have a '/public' folder with more
permissions for the 'anon' role.
- Bert -
Am 29.08.2005 um 13:32 schrieb Roel Wuyts:
I see.
I'll play with this and see what it gives.
Thanks!
On 26 Aug 2005, at 11:54, Bert Freudenberg wrote:
>
> Am 26.08.2005 um 11:12 schrieb Roel Wuyts:
>
>
>
>
>> Hello,
>>
>> I have a question for SmallWiki 1 (since it is for my
>> "production" wiki)...
>> I would like to protect part of my SmallWiki site (my "intranet")
>> such that people have to login to even view that part. The rest
>> of the site (the public part) still needs to be visible to
>> anonymous (but editable by admin).
>>
>> Is there a way to support this scenario ? From what I understood
>> this is currently not possible (e.g. Roles are global). Am I
>> correct ? Anybody made extensions to allow for this kind of
>> scenario ?
>>
>>
>>
>
> It's possible in the current implementation without extension. The
> key is to give permissions only to the structures, not to the
> users. When a user tries to access a structure, the permissions
> are taken from the structure. I think the following should work
> for you:
>
> - anonymous user:
> -- role 'anon' (no permissions)
>
> - registered user
> -- role 'editor' (no permissions)
>
> - root folder '/'
> -- role 'anon' (allow read)
> -- role 'editor (allow read and write)
>
> - folder '/private/'
> -- role 'anon' (no permissions)
>
> I'm not 100% sure if you can indeed "take away" permissions in the
> subfolder, you need to try that.
>
> We employ an even finer-grained scheme with write access for
> different users in different folders. For that, we give each
> folder a separate role with write permissions (the role is named
> after the folder). When a user should be allowed to write in that
> folder, it is assigned a role with the folder name (but again
> without permissions).
>
>
> - Bert -
>
>
>