On 27 March 2011 11:38, Hans <[email protected]> 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 versions. eemeli ---------- Forwarded message ---------- From: Eemeli Aro <[email protected]> Date: 15 June 2010 01:32 Subject: Re: pmwiki: authuser backend To: Peter Bowers <[email protected]> Cc: Petko Yotov <[email protected]> Bother. 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 occasionally. 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 array. 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 work). 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. eemeli _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
