Current behavior

acl_rights_before, acl_rights_after

What we right now have is a force rule ( before / after ), to force rights on pages. After defining that kind of rules, you cant change them on the whole wiki. They are forced in any way. For superusers or "without compromise" admins of the wiki, whis is usefull, so a feature to keep.

acl_rights_default

Asigning a default ACL if the pages has none yet can be usefull, but only for really simply cases. Because you cant use the default-acl and then add somthing or just remove something from it by a ruleset. This is simply not possible. So you always have to copy the full default-acl-line to each page and then change it, what is, in my eyes..quite unhandy for a bit complexer uses. It`s then just "unbelieveable work" to change the default behavior..because you cant just replace the 2default-acl"...you will have to look on each site which where restricted by a 2custom" default-acl.

* yeah exactly. You add a keyword to let the site act "default"..what makes in not default. It should be somehow just the opposite, adding a "NonDefault" to exclude the default ACL would be the right way, in my eyes. But i must admit, that way works quite well. Maybe just change the behavior from DEfault being included always, and the keyword "NotDefault"~~~~ xored

Here is an example:

acl_rights_default = u'EditorsGroup:read,write,delete,revert UsersGroup:read,write'

Lets say you want to prevent editors to delete certain page, and use the default rights otherwise. Add this acl to the page:

#acl -EditorsGroup:delete Default

New behavior

acl_default_merge

This ACL should used, if you want to have a default line, which is applied to each page, but which you can change because it will be "merged by some rules" before being applied to the page. So lets sa we have :

acl_default_merge=AdminGroup:read,write,delete,admin All:

What we now have, normaly, is a AdminGroup is able to do just anything, even edit there own AdminGroup Page and add new admins, what could be risky! So now we want to change this one one the AdminGroup page

#acl -AdminGroup:admin

done. and recognise if we would have used before/after for AdminGroup:read,write,delete,admin All: we simply could not do this at all!

Or we want to give everbody access to a page, which still should be administrated by the AdminGroup

#acl +All:read

And what we ofc want is something like disable the whole "acl_default_merge" for a page and define fully new acl rulesets:

#acl NoDefaultMerge User:read Group:write

That are the rules i used



Code Stuff

What we currently have is a wikiacl.AccessControlList.addLine function which parses a new ACLstring and adds it to the current ACLs in the AccessControlList. This is currently not used that way in the moinmoin, as we only support one #acl line in the page, what is ok i guess.

What will be new is a wikiacl.AccessControlList.mergeLine which will just merge the given aclstring witht the currentAccessControlList. with the rules i described. In addition, i had to change the tuple of entry/right under wikiacl.AccessControlList.acl. Before, it was a 2xtuple holding(entry,rights), now it is a 3xtuple with (entry,rights, modifier).. because we need the modifier for the rules. Nothing big to change, changing

to

and of course

to

~~~~ xored

I did not have time to read you suggestion, but generally it looks confusing. I suggest you collect first some use case that the current system can not handle or hard to use, before you suggest a solution. -- NirSoffer 2007-02-16 18:17:15 * Sorry but you "dont have time"..but in "generally looks confusing". Take your time to read and write down what is confusing. Your comment is just usless that way. ~~~~ xored


CategoryFeatureRequest

MoinMoin: FeatureRequests/NewDefaultACLFeature (last edited 2007-10-29 19:13:37 by localhost)