Philippe implemented a capabilities (ACL) based security model. It
worked very well, but IMHO was too complicated to setup properly and
use (due to the complete freedom).
Security is currently based on commands, something like create value
links or edit verbatim text does not really fit into that model. What
you could easily do however is to create a restricted edit command
that doesn't allow to edit these elements. This would follow the
pattern of 'edit page' and 'settings page' (earlier on everything was
in 'edit page').
Lukas
On Friday, 22 July 2011, Nick Ager <
[hidden email]> wrote:
> Hi,
> I can understand how the current implementation of Pier security could work well in the case of a set of users each with their own sub-tree - a little like Unix's '/home/user1' '/home/user2' etc, where users can control the commands allowed to be executed on their sub-trees.
> However I'm looking for a more capability model, for example:* does the user have permission to see this view in wiki mode? * does the user have permission to create verbatim html?
> * does the user have permission to create value links?* etc
> Is there a sensible way to map this onto the current security implementation? I've currently mapped it with code like:
>
> editorConfiguration allowWikiTextEditing: ((self context command: PRWikiTextEditingCommand new) isValid).
> This works however the owner/group/other structure permissions mapping seems too coarse grained. I'd like to be able to have groups relating to these permissions then add groups to users, depending upon the permissions I'd like to assign to them. Am I looking at this in the wrong way? Is there a mechanism to support a capability model?
>
> Cheers
> Nick
>
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Locked
