[Moin-devel] Page Permissions

[Nick Trout]

> From: moin-devel-admin at lists.sourceforge.net 
> [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of 
> Juergen Hermann
> Sent: January 29, 2003 2:36 PM
> On Wed, 29 Jan 2003 12:26:08 -0800, Nick Trout wrote:
> 
> >One file for each page would probably be easier. Where would 
> be a good
> >place to put these files? Should I create a new directory 
> called, say,
> >data/editlocks? 
> 
> The relevant function is MoinMoin.wikiutil.getPagePath(). See 
> the source 
> for usage examples.

Ah that is not in my version. I updated from a CVS tar a couple of weeks
ago I think. I'll get latest tomorrow.

> >This is what I have done so far. I wanted to know if there 
> was a way of
> >doing this without altering the Moin code base. Having a personalised
> >site permissions would allow you to lock certain pages to 
> certain users
> >without altering the Moin code. However you can only stop 
> editing, not
> >manage editing, with the current set up. I will look into 
> simplifying my
> >implementation to using individual lock files.
> 
> The idea of abusing the Permissions is, well, an abuse. ;)

I don't understand how that is abusing the Permissions. I thought the
whole point is that you just derive your own ones and attach them to a
user and this could be altered per site. Currently you can't really do
much with the permissions, just find out if someone may read or edit the
site and it looks like this pretty much has so be set on construction
because nothing is passed to the "may" permission object to be able to
alter its behaviour at runtime.

> What we could do is to sprinkle core code with different 
> kinds of hook 
> interfaces (which Persmissions already is).
> 
> i.e. we would have something like config.EditorHook = 
> "MoinMoin.mymodule.MyLockingEditorPlug"
> 
> and call methods like save(), preview() etc. in those hook classes.
> 
> This would surely not solve all cases where you need to 
> extend code, but 
> it would help for many common cases.

This is what I came up with as well. How useful would it be though. Just
to lock pages is a matter of reading and writing a lock file, which
could be patched into PageEditor. It might be nice to have the facility
to use Permissions to do more complicated behaviour but its not really
necessary.

It would be nice to be able to set different levels of access e.g.
Administrator can add new users and edit anything.
Manager can read, edit and create pages.
Editor can read and edit pages but can't create.
Reader can only read pages.

You could block anonymous users and have them apply to the admin for an
id to restrict access to sensitive information. This level of
functionality probably goes against wiki simplicity and ethos but there
are situations where it would be useful so you can manage the flow of
information. I'm not suggesting these changes for this simple feature
I'd like to add now but they'd be nice for the future.


> >> Perhaps it is more worth to put some work in collision resolving.
> >
> >How would you suggest doing this?
> 
> Like CVS does it (3-way merging). The idea is already buried 
> somewhere in 
> the wiki.

I'd rather warn people a page is busy. Any merge could create a right
mess if there are extensive edits and someone will have to sort it out.