[pmwiki-users] Privileges Cascade

[H. Fox]

On 1/21/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Fri, Jan 20, 2006 at 04:51:57PM -0700, H. Fox wrote:
> > How can I accomplish the following in skin.php:
> >
> > Edit privileges give you read privileges.
> > Upload privileges give you read and edit privileges.
>
> Short answer:  I think skin.php is very much the wrong
> place to do this sort of customization -- it belongs
> in config.php somewhere.  As such, I don't (yet) know of
> a good way to do it from skin.php.

There probably isn't one...

> Long answer
> -----------
>
> From a design perspective, I don't believe that
> operational/behavior changes such as this belong in a "skin" --
> and I'd prefer that we limit the use of the word "skin" to
> things that are primarily cosmetic (i.e., that directly
> determine the display) and not start to include too many
> functional/behavioral aspects in skin code.

I'll call it whatever is appropriate.

> This isn't to say that there's anything wrong with combining
> output cosmetics with functional changes into a single package,
> but at that point I think the package ceases to be a "skin" and
> becomes something more substantial.  As such, we should then
> *call* it something other than a "skin" and treat it more like
> we do other functional changes and less like a "skin"; i.e.,
> it should be done with include_once('cookbook/...') instead
> of $Skin = '...'; .

It's looking like what I really want to do is bundle recipes with the skin.

Maybe code that needs to be called from config.php can be included
with something like include_once('pub/skins/skin_name/cookbook/...').

[...]
> So, back to the original question -- I can agree with the idea
> that someone with edit privileges should also automatically get
> read privileges.  It's something I've been wanting to add to the
> core, but I didn't want to just hard-code a "edit implies read"
> rule, because it needs to be customizable and I'm still working out
> the details for that.  More on this in a bit.  But as a direct
> counter-example to the idea of hard-coding this particular logic,
> I'm not so sure that upload privileges should automatically confer
> edit privileges -- I can envision applications where uploading would
> be allowed but not editing (e.g., students submitting homework
> assignments through the wiki, or a file sharing repository).

Hadn't thought of that.

Personally I'd be "least surprised" by upload-confers-edit as a
default that could be overridden by local configuration.

> What I am fairly certain of is that skin.php isn't the place
> to be making changes to the authorization system.  :-)

Now I understand.  Thanks for explaining.

>  I'm not
> entirely sure of the motivation for wanting to place this into skin.php
> (as opposed to a config.php item or other cookbook recipe),

My motivation is to integrate CMS behavior into the LeanSkin and, by
doing so, save a lot of work that would otherwise be necessary to
CMS-enable a site.

> but at
> first glance it seems to me to be something that ought to be orthogonal
> to (and therefore available separately from) a "skin".

It's not entirely orthogonal because some of what appears in the
skin's template will depend on the presence of recipes.

> Possible solution
> -----------------
>
> I've been thinking that a possible way to cascade permissions like this is
> to simply allow $HandleAuth to contain arrays of authorization levels
> as well as a single level.  Thus, one could do:
>
>     $HandleAuth['browse'] = array('read', 'edit', 'upload');
>     $HandleAuth['edit'] = array('edit', 'upload');
>
> which says that ?action=browse is available to anyone with
> read, edit, or upload permissions, while ?action=edit is available
> only with edit and upload permissions.

That would do it.

> I haven't committed to this yet because we also have the
> outstanding issue of dealing with the edit password on Site.SideBar,
> where we want to have some setting to use the site default password
> instead of the group-level one in Site.GroupAttributes.

This, too, is important for what I'm trying to accomplish.

Another page where it would be useful is Site.AllRecentChanges.  (I'll
skip explaining why.  :-) ).

>  That's yet
> another type of privilege cascade, and I'm thinking that the
> "edit confers read" cascade and "Site.SideBar uses site default"
> cascade might be two special cases of a more general solution
> that I'm just not seeing yet (and I'd much rather build a single
> general+flexible solution than multiple special-case ones).

I understand.

Thanks for the detailed and helpful reply.  It provides the
perspective I need to move ahead with the "Instant CMS" project.

Hagan