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

• Eases the task of administrating special content areas
• By using the correct template (a habit the special editor group should always follow) it guarantees the correct access rights, no matter where the page is created.

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.

• The ACLs intended to be passed to the new pages would also apply to the template itself
• Nothing forces pages created from the template to be inside of the sub-wiki (same as now}
• Changes to the ACLs on the template would not apply to pages already created (same as now. Only hierarchical ACL could solve this, I think}
• Existing templates with ACL would inherit this new behavior. How big of a problem would this be?

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

• I think that would meet our needs. Although a bit more cumbersome, it's better than nothing. Thanks. -- SteveDavison

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

• My suggested implementation may be flawed, but I think the overall capability would be useful. For my situation, though, I think that hierarchical ACL would be the best cure, assuming it's implemented the right way. Is hier. ACL slated for 1.6, and if so, which flavor? There's so much written about it in so many places, I can't tell what its status is. Thanks. -- SteveDavison

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

• I think you missed something... AutoAdmin grants admin rights, but does nothing to alter read or right privileges. -- SteveDavison

• AutoAmin does not automatically grant specifically admin rights - it allows the user to create a page with a (predefined) ACL line which would be normally forbidden (it may the the admin right but it may also be just a read right). Did you look at the code of AutoAdmin to see what it really does? I hadn't understood it from the description in the help but looking at the code made it clear. I have to admit that even after re**3-reading your scenario I don't get what can't be solved with present (1.5.7) moin. But that's no problem. -- DavidLinke

• Here is what I have in mind: (I hope that it is correct as I write from memory.)

  1. Add Project1/AdminGroup to the page AutoAdminGroup

  2. Create a template named "Project1Template". Contents e.g.

     • {{{#acl Project1/AdminGroup:read,write

...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.

• The page HelpOnAutoAdmin is rather confusing and needs a rewrite. I'll credit that for our wildly varying understanding of the feature. Here's what I know for sure... If I create a page named project1/AdminGroup, and add JimBob to it, then add project1/AdminGroup to the page AutoAdminGroup... then the user JimBob will be able to add/edit ACLs for any subpage under project1.
  

• As for the steps you listed above... What that actually does is grant admin rights to everyone listed in Project1/AdminGroup for all subpages of Project1. THAT is what allows any of those users to create pages with #acl lines. Granting read/write to Project1/AdminGroup via the #acl in the templates is in essence saying, "If you have admin rights to this page, we'll let you read it and write it also".

  • Ok, you are right. Now your feature request makes perfect sense. -- DavidLinke

So the two problems with the above solution are:

• I don't want every contributor to Project1 to be granted admin rights, meaning I can't add them to Project1/!AdminGroup.

• Without admin rights, a contributor can't base a page on a template with ACLs (it won't save). And with out ACLs on each of the pages, there doesn't appear to be any way to restrict access to only a specific group.

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