<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Sep 28, 2006, at 4:49 PM, Patrick R. Michaud wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">It also shows why we really ought to have a good</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">comprehensive membership management system that integrates<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">well with PmWiki; either as part of the core or as a</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">well-maintained recipe that is maintained along with the core.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>I already expect to tie-in the ability for an admin or group of @admins to manage the mysql user database I created with XesAuthUserDbase from within the Wiki. That feature along with an option to email an admin when a new user completes their registration will help achieve this goal.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>After that, I will wrestle with Koopsmailinglist to create a wikified tie-in to manage newsletters. If/when we have the ability to encapsulate the HTML output of any specific page into a variable a recipe can use, I'll make it an option to send a specific page in the wiki or to use a webform to send an email to the list (which is one way you can use Koops as it stands).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Does that work? What other features would such a system require? Would you want to be able to manage groups from the admin panel, because that was one consideration I had when I first conceived of XesAuthUserDbase, then decided it was very easy to manage groups from Site.AuthUser. One feature I would suggest from Site.AuthUser is the ability to nest groups, however. [ @moderators: @forumowners, joe, kelly, sue ] It has the potential to save a lot of repetitive typing. If that already exists, I didn't see it mentioned in the documentation on Site.AuthUser</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>XesAuthUserDbase has:</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>- user self-sign-up</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>- email validation of the user (I should make this one optional in the future, so you can simply have people sign up without email validation -- the admin may want to personally validate/approve members.)</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>- user can request password change if they've lost their password (sends them another email validation)</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>- user can manage their password and email address</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I have a to-do list on the documentation page for some tweaks I would like to make. Ben Wilson would also like us to merge the forks of XesAuthUserDbase and AuthUserDbase back together for a single solution to multiple issues, and I agree with this. The less recipes there are floating around the more clear it is what recipe people need.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The methodology I use for users to self-sign on may be able to be extended to (htaccess &/or in-wiki only) AuthUser signups. However, while this is certainly necessary on some sites, I still use PmWiki with a global edit password as a single-user website management program, and I still use it as an entirely anonymous open-edit system. Adding comprehensive user management to the core may or may not be wiki-ish. I personally consider it more a feature of CMS systems than wikis, and although I won't argue about putting this feature into the core, I do consider it approaching the point of incorporating a feature many people will consider very optional.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Crisses</DIV></BODY></HTML>