[pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

[The Editor]

On Thu, Jul 10, 2008 at 5:26 PM, Eemeli Aro <eemeli at gmail.com> wrote:
> 2008/7/10 The Editor <editor at fast.st>:
>> Though I'm no longer actively supporting ZAP, it's been able to do
>> this and much more for a long time.
>
> I actually did take a look at ZAP and the MemberMgmt recipe before
> starting, but it's that "and much more" part that turned me away. By
> now, I know how PmWiki works; I've read through the code enough times
> to trust what it's doing. Admittedly Pm's code could do with more
> documentation aimed at developers and longer variable names, but it
> does all work and lets me pick which parts to enable or disable.

Just thought it might be helpful to have something that is already set
up for what you are doing. But then again, support these days for ZAP
is pretty limited.

> ZAP, on the other hand, is a single monolithic recipe that proudly
> lists 30 different things that it does. The effort I'd need to put
> into understanding all of it exceeds the effort I'm putting into
> writing what I need myself. Since we're dealing with account
> management I figure I need to be extra careful with what I do.
> Essentially, I don't think I need generic form processing with extra
> features to enable account administration.

Actually, ZAP is a pretty simple platform, with a bunch of extension.
The core engine is lean (under 400 lines).  And the toolbox is just a
collection of standalone modules. And everywhere possible, ZAP taps
directly into core PmWiki features (from security to page creation to
whatever, so it works closely with PmWiki). What I've suggested to
others (for better performance and security both), is to just delete
or comment out any functions you don't use from the toolbox. If all
you want is member mgmt features--that means you'ld only need another
30 or 40 lines more. Hardly monolithic.

> Additionally, there are quite a few things that I need that I haven't
> seen ready solutions for. For example, I want to have
> <example.com/wiki/SomeUser> resolve to a default profile page for
> SomeUser that reads a template from somewhere and SomeUser's data from
> elsewhere. The tricky part (or at least one of them) is the lack of
> any default group for these profile pages.

If you could get by with example.com/wiki/Login/SomeUser you could do
this today in ZAP. I just put a template in the header of the Login
group and populate it with data saved from their registration form.
You can even have a form that allows members to edit their profile
data. As in a button at the bottom if the page name matches their
member id.  I don't know there is a ready made snippet (probably is),
but this is the precise purpose ZAP was created for. And I do it all
the time in BoltWire.

If you can't have the group name (login), surely a line or two in a
config file could be used to check the page name, and if it matches
some pattern you simply redirect to the desired page. But using
Login/SomeUser means you can put a link like [[login.{member}|View
Profile]] on a page, or the usual ~~.

> Another odd feature that I want is controlled, undoable deletion of
> other people's user accounts by non-administrators. Most of my sites
> are internal, and what with the restructuring and changing secretaries
> and other things, it's not always clear if someone's still an employee
> or not. And since keeping track of people really isn't my job, I
> figure I ought to make it possible for anyone to update these details.

This should be a snap in ZAP. Because their login information is
embedded in their in-wiki login page,anyone with permission can simply
delete a login page and the password and all data vanishes instantly.
Plus you don't have to give them access to any critical site pages or
config files or the like. And if a page were accidently deleted, you
could always retrieve it like any other deleted PmWiki page as an
admin.

Anyway, feel free to pursue other options. I'm not pushing ZAP or
offering to help.

Cheers,
Dan