Request: Newly Created Pages Inherit All ACLs from Template

I'd like to see the ability for non-admin users to create pages with stock ACLs by basing the page on the appropriate template.

Target Audience

Anyone who wants their wiki to have special content areas with different access privileges than ordinary pages, but where more than one person will be working on these pages. Examples: secret or sensitive information, help or policy pages, pre-release pages that you want to remain hidden from the average user...

The Problem

Scenario: Consider that want to protect a group of pages from being viewed and/or edited by all but a select group. You may wish to protect some sensitive or secret information, or control editing so that the pages are kept to a higher set of standards (not unlike MoinMaster...)

In order to lessen the work of the primary wiki administrators, AutoAdmin can be used to assign some sub-admins to the "sub-wiki".

The problem is that every page that one of the privileged users creates within the "sub-wiki" will be accessible to every user, which completely violates the purpose behind creating the subwiki in the first place.

Currently, the only way I know of to deal with the problem is to have an admin monitor all page creations in the sub-wiki, and then edit each new page to add the ACLs that give the pages their special protection. But this is too high-maintenance.

Proposed Solution

One solution has already been suggested in FeatureRequests/AclStoreOnCreate, including a patch. This solution allows any user to add ACL when creating a new page. One problem is that this requires the page creator to generate the correct ACL each time, and does not prevent them from entering the wrong privileges. I would like to see a more structured, controlled method.

It goes like this... The admin of the sub-wiki will create a template page that contains the appropriate default ACL line for this area. MoinMoin would have to be changed to allow #acl lines to be passed through to the new page even if the creator does not have admin rights for the page he/she is creating.

The only thing keeping this from working right now is that the creation of pages from templates is no different from creating a blank page and pasting the template text into the edit box... so when a non-admin tries to save the page it will fail because Moin does not distinguish between whether the ACL that came from the template or whether the user tried to add it.

In a way, this could be viewed as building on the solution provided by the AutoAdmin feature. But in many cases, it would replace the need for AutoAdmin altogether. By placing a +SpecialAreaAdminGroup:admin clause in the template's ACL, every page created with that template will grant admin rights to the appropriate group. (This would be the same admin group you would add to the AutoAdminGroup page...)

Benefits

Imperfections
I call these imperfections, rather than drawbacks, because I don't think any of them are worse than how things work now (1.5.7). This is a limited solution and does not try to solve everything.

Proposed Changes

Sorry, these are only pseudo-code... still learning python and Moin code.

After Choosing Template

if user doesn't have admin rights to new page or template:
    remove #acl line from template text before populating editbox
    save acl in hidden field on edit form

When New Page is Submitted

Check for any errors (as usual}, including non-admins trying to add ACL
Prepend page text with any contents of hidden ACL field

Discussion

You can use the new CopyPage action which comes with 1.6 to copy a page with acls. So you can use it for your acl templated pages to create new pages -- ReimarBauer

Aside from that, this feature request contains 2 sub requests:

  1. user interface change for ACLs (not) editing
  2. acl handling from template

While the first seems nice for user experience, you can't trust it, relying on the content of that hidden field. A user using some tool could modify the acls kept there.

Further, we will split off acls to meta data some time and we will need some kind of meta-data editing then. Thus a change in UI should be a) generic for meta data and b) delayed until that happens.

-- ThomasWaldmann

As far as I understand the goal is to create a group of pages topicA/page1, topicA/page2, topicA/page3 which is just editable/readable by a restricted group of users? This kind of "scenario" can be solved by AutoAdmin (see "Enabling another (project) page for AutoAdmin" on HelpOnAutoAdmin). Do I miss something in you scenario description? -- DavidLinke

...rest of template... }}}

  1. Create a page Project1/AdminGroup with the names of the users that should have access (read,write in this case).

  2. To help users creating new sub-pages under project1 you might want to add [[NewPage(Project1Template, Make a new Project1 sub-page!, Project1)]] to the "start-page" project1.

So the two problems with the above solution are:

In HelpOnAutoAdmin, it implies that the ReadGroup and ReadWriteGroup subpages can be used with project-type autoadmin as well as user-page autoadmin. This would solve my problems beautifully, but... there's no explaination of how to use them. I know that ReadGroup and ReadWriteGroup are "special", because I can only edit them as an admin. But so far I haven't been able to get either of them to do anything.

-- SteveDavison


CategoryFeatureRequest

MoinMoin: FeatureRequests/TransferAclFromTemplatePage (last edited 2007-10-29 19:06:11 by localhost)