Making Moin better ;)

Some proprosals for making managability of ACLs easier.

• I don't see how any of those makes something easier or better, it just complicates things. Looking at quite some users having problems even with the current, more simple system, I don't see any advantage.

Creator and Last

Each page has at least 2 well determined revisions, that is the first one, and the last one. The users who did those could be referenced by the names Creator: and Last: (maybe one can think of better names). Adding the proper rules to the default rules will make it easier to delegate wiki maintainace to users like: Creator:admin Last:revert

Problems:

• Anybody can create a page or create the last revision. Why do we want to give special rights to random users?
  • that might be constrained by other ACL's it should just extend the rights for someone to maintain his own changes. This might not only be used to give special rights, also to constrain rights. Example usage could be some rateing system (u know ebay?) ACL's can be set up that one can Create a page or add a comment, but never again change it. There are prolly lots other uses ... and the First and Last revisions are quite well defined handles, would be just a nice feature to expose them to make something useful.

• Any name we add takes possible name from real user, e.g. JoeCreator, who would like to register as Creator

  • hey next time i try to get the username All or Known here ... seriously: the names where only meant as example Moin should provide a set of reserved names to make this clear and enforce that no user named like these . U'll find some nameing scheme right?

• Being a creator of a page doesn't mean one has more rights than any other editor of that page.
• Old pages might get purged, including creator info.

• I see even less sense in Last:.

self_..

some right might benefit from a self_ prefix as in self_revert or (likely more complicated) self_write which restricts the actions to content which was done by the user itself (one might revert his own changes, or correct text he created)

• Its not clear how this will be used

  • #acl All:self_revert,read anyone can revert back to a state he created (maybe removing a couple of later revisions)

  • All:self_read,self_revert,self_write in default acls -> people can always maintain pages they worked on, without careing about acl maintainace by themself .. in fact the wiki maintains proper access rights for a user even if the user has no admin rights on the page

  • the self_ idea was something i had before the Last: and Creator: thing, the functionaity overlaps slightly but also complements each other, an other way might be to implement creator_* and last_* rights as in All:creator_revert,... or such. But tieing the user-lookup to the permission side of the acl looks bit wrong.

• I think that self_* stuff can get quite complicated. If some people edited on a page, it might be unclear what belongs to self and what not. And even if you just define it somehow, it still is questionable whether that definition makes sense.

add

Its likely trivial to determine if a diff contains only additions and no deletes. It would be quite useful if pages can restrict access only on additions (like commenting systems). a new right called add would be nice for such.

• You mean, the user will be able to add text but not delete? So you can't edit existing lines, but only add lines?
  • yes, simple or?
• Problem: once saved, you couldn't even edit your own typos.

access macros

currently the Wiki only exploits low-level access rights (read,write,admin,...). These could be grouped to higher level convenience rights, which just acts like a macro processor example: "edit"="read,write,revert" then Foo:edit will be just the same as Foo:read,write,revert.

This might be too complicated. How about class based rights?

read
    write
        revert
            delete
                admin

If you can write, you can also read, as it does not make sense otherwise. If you can delete, you can write and read and revert.

Instead of:

#acl User:read,write,revert,delete,admin

We can use:

#acl User:admin

• Complicated??? ... it's just text substitution, before doing any other processing! And no the I think ur class based proprosal is unacceptable, johill even proprosed JohannesBerg/PluggableACLs, he showed me that stuff after I added this feature request. I think it will nicely play together. The class based system makes it far more inflexible.

• this macros where meant to be defined in the wikis config file, so the wiki administrator can configure them to his needs. (edit does not need to mean the same on any wiki, someome means only read,write while someone other wants read,write,revert,delete). just a dict ACLmacros={"edit":"read,write", "comment:read,add"} is prolly enough, when a page is parsed the acl macros get just substituted before anything else. I would vote for making the wiki config a wiki page by itself, but that is quite another theme.

  • user configurable ACL macros just make things worse, when every wiki admin invents some macro names and nobody will know how exactly xxx behaves in wiki A vs. wiki B. Less can be more.

ACLs for creating subpages

This is something I can't do with just acl_before, acl_default and acl_after, and it's the only way (?) I can set ACLs for non-existing pages.

The proposition is to add a create right (maybe subpage, add or child would be better?).

This right woudn't apply to the page it's on, but to it's (immediate) subpages - basically granting the write right.

You could maybe achive similar result with something like #child_acl: something:write, that would allow you to specify the ACL for non-existing subpages.

Discussion

Most of these suggestions have one problem - they don't solve any real problem with acls. We should not make the acl system more complicated or configurable, we should make it simpler to use and prevent user errors. User error in acl definition can mean your private information can leak.

If you want to have custom security policy in your wiki, go and write custom SecurityPolicy, you can do anything in this code, including adding custom acl rights etc. -- NirSoffer 2005-02-17 21:40:28

I don't see those features making moin easier or better, I think it would just complicate things. See also my comments above. Therefore, for now:

CategoryFeatureRejected