<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Re: [pmwiki-users] Question about (:if expr auth admin:)</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText60893 dir=ltr>
<DIV dir=ltr><FONT size=2>> For the two wikis that I manage, I am looking for
these two aspects of a<BR>> 'solution':<BR>><BR>> a. access rights
based on groups (the ability to grant each user access<BR>> rights to
specified groups, with a default for the entire wiki)<BR><BR>By "groups" here
are you referring to "groups of pages" (i.e., WikiGroups)<BR>or "groups of
authors"? authuser.php already has the ability<BR>to control access to
WikiGroups by individual users.<BR><BR>> b. web-based management panel to
remove the need to hand-edit<BR>> local/config.php or a passwd-formatted text
file<BR><BR>What features does the web-based management panel need?<BR>Is it an
"admin-only" interface, or do visitors need the ability<BR>to use it as well
(e.g., to create accounts, recover lost passwords,<BR>etc.)?<BR></FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Yes, I'm referring to WikiGroups as they're
implemented in PmWiki.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>I think I've got this straight... authuser, while it
works exactly as designed, has a couple of major drawbacks for my
application. First it still requires me to edit local/config.php.
Second, unless I assign users according to a convention that can be matched
via a wildcard (using id:p* for example), I need to update the access list for
each group for each user. This is the wrong way around because it means I
have to make multiple edits for each user twice, once when adding the user and
again on removing him/her. It would be more natural for me to type or select the
groups as an "attribute" of the user, then have the permissions removed with the
user. Also, I want users to select their own user ids and perhaps ultimately to
piggyback on LDAP or some other sort of authentication for our
intranet.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>The result is that group permissions need to be
associated with users, not the groups themselves.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>On your second question, admin-only will do to start.
There are cookbook solutions for things like password changes. Actually I
started a laundry list of functionality needed by admins and users then held
back because the list seemed to be growing to incorporate things like "recover
lost passwords" (which I think would be great) because they might be beyond a
more minimal definition of the changes I critically need.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>I'll build the list anyway since it might be useful. I
was collecting everything I could find from places like UserAuthDevel and
starting to think about the fields and buttons it would take.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Chris</DIV></FONT></DIV>
</BODY>
</HTML>