[pmwiki-users] UserAdmin templates

Eemeli Aro eemeli at gmail.com
Mon Mar 28 02:31:45 CDT 2011

On 27 March 2011 11:38, Hans <design5 at softflow.co.uk> wrote:
> I am using the scripts as found attached to Cookbook.UserAdmin.

The versions of useradmin-core and useradmin-profiles there were
2010-06-07/08, and it looks like the latest that I got to since then
were versions I sent to Peter on 2010-06-14. To help things forward,
I've now added those to
<http://www.pmwiki.org/wiki/Cookbook/UserAdmin#relnotes>. Also below
is the accompanying email I sent, which is the best (read: only)
documentation for the changes between the -07/08 versions and the -14


---------- Forwarded message ----------
From: Eemeli Aro <eemeli at gmail.com>
Date: 15 June 2010 01:32
Subject: Re: pmwiki: authuser backend
To: Peter Bowers <pbowers at pobox.com>
Cc: Petko Yotov <5ko at 5ko.fr>


I'd hoped to have this more done by now, but I guess it's not. In any
case, here's the latest. I won't have much time for PmWiki stuff
during the next 2-5 weeks, and I'll be in reach of email only

I'm CCing a copy to Petko, in case he has something to say on the
direction this is heading. Apologies for the lack of context, but
hopefully (if you're interested, that is) the cookbook text and the
code itself is clear enough to give some understanding.

I did the sane thing (ie. what you suggested), and separated user &
group read/write functions from each other. All group data is now
being handled in SiteAdmin.AuthUser, and ReadUser won't even return
any group information.

SiteAdmin.AuthUser access is not quite as nicely mirrored for
read/write as page attributes are, mostly due to the various possible
@group definitions. For reading, the lowest level is AuthUserPage(),
which reads all the valid data into a 2D array. That is then used by
eg. Groups(), which parses the group information into a similar 2D

Writing to SiteAdmin.AuthUser currently only happens via WriteGroup(),
which uses DelValue() and AddValue() to actually modify the $page.
Values are removed from both "user: @group" and "@group: user" lines,
but only added to the latter format. There's a possibility that LDAP
values may break Add/DelValue if they contain similar strings and
commas -- this'll need looking into.

Unless I've made some unfounded assumptions, this should mean that you
only need to overload/modify AuthUserPage(), DelValue() and AddValue()
to use a different/extended data format. Also extended @group syntax
(surprisingly simple to implement, actually) should only require
changes to Groups().

user/group isn't fully functional yet, ie. the POSTed data is just
printed out. Really though it's only rather minor input processing
that's required + a call to WriteGroup (which I have tested & seems to

user/edit and user/group leak data about user and group names: this
will need fixing. Also attempting to access eg. user edit pages gives
different results for existing and non-existing users, not sure if
this needs to be fixed somehow.

So, I'm leaving this to you for the next few weeks. Feel free to
refactor, re-think or do whatever with the code. I did kind of step on
your turf a bit due to changing my mind about where to put group
information, so if your structure or approach would be easier to
implement with some (even major) changes or additions, do modify the
core. Also, if you feel confident enough feel free to push a release
to pmwiki.org.


More information about the pmwiki-users mailing list