<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Tegan,<br>
<br>
That worked for the group. <br>
<br>
I'm a little surprised by this though:<br>
<br>
1. Last time I checked, to edit a page you need to be able to read it
(ie read permission is implied), therefore conferring edit rights
should most certainly confer read rights.<br>
<br>
2. Requiring explicit matching of passwords where site-wide rights
should be conferred to groups, obstructs the intention by creating
unnecessary administrative work (should the site-wide password have to
change). Seems to me letting groups and pages inherit rights through
@_site_edit (ie @_site_&lt;whatever-right&gt;), and also letting pages
inherit group rights with @_group_edit, would make sense, and be
natural and symmetrical. The current situation, given the potential
time and errors involved in changing a password scheme is, ironically,
a security risk.<br>
<br>
3. The apparent application of the publish password to the attribute
password in the group is just plain nuts (ie a bug.).<br>
<br>
Looks to me like this password system could use a bit of attention.<br>
<br>
How does all this compare with generally accepted permission scheme
standards? Am I missing something?<br>
<br>
- Henrik<br>
<br>
Tegan Dowling wrote:
<blockquote
 cite="mid:5c8455a0805121953v273b25f7ycaaa44cc9cc55058@mail.gmail.com"
 type="cite">
  <pre wrap="">On Mon, May 12, 2008 at 5:12 PM, Henrik Bechmann <a class="moz-txt-link-rfc2396E" href="mailto:henrik@bechmann.ca">&lt;henrik@bechmann.ca&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">When I login with a site-wide edit password, I am challenged for an
 additional *read* password for a group for which I have set a read password.

 I'm having a little trouble fathoming this. I thought that an edit
 password trumps a read password.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It doesn't.  Read and edit permissions are set separately, and edit
rights do not confer read rights, any more than read rights confer
edit rights.

If, in your config.php file, you have

        $DefaultPasswords['edit'] = crypt('userpasswordhere');

Then in any wikigroup named, for example, ProtectedGroup, you need to
use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = userpasswordhere

OR use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = specialgrouppass userpasswordhere
Set new edit password = specialgrouppass userpasswordhere
(create a space-separated list of passwords for each attribute)

You cannot use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = @_site_edit

That doesn't work.  In discussion in this list-serv in 2006, PM said
that he never intended @_site_edit to be used on
GroupAttributes?action=attr.

(Everybody please VOTE on <a class="moz-txt-link-freetext" href="http://www.pmwiki.org/wiki/PITS/00836">http://www.pmwiki.org/wiki/PITS/00836</a>).</pre>
  <pre wrap="">
<hr size="4" width="90%">

No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.100 / Virus Database: 269.23.16/1429 - Release Date: 5/12/2008 6:14 PM
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 

Henrik Bechmann
bechmann.ca
Webmaster, celos.ca webhosting services</pre>
</body>
</html>