On TWiki.org, TWiki:TWiki.SitePermissions aggregates the ALLOWWEB* settings in WebPreferences for all webs.

It does not work on my installation of Dakar (but I've just noticed it works on develop.twiki.org). Weird.

---

What do you mean "it doesn't work"? Specifics? CC

---

Note that SitePermissions is misleading; Setting ALLOWTOPICCHANGE to the null string is not the same thing as not setting it. SitePermissions must be fixed to reflect this, or removed - otherwise it is dangerous!! CC

---

I've updated SitePermissions to include a warning about this. However thr underlying problem still needs to be addressed. - AA

---

What underlying problem?????? CC

---

That the display presented by TWiki:TWiki.SitePermissions can't communicate the difference between the difference between

   * Set ALLOWWEBCHANGE = TWikiAdminGroup
   * #Set DENYWEBCHANGE = 

and

   * Set ALLOWWEBCHANGE = TWikiAdminGroup
   * Set DENYWEBCHANGE = 

If I understand correctly, the former resticts modifications to the TWikiAdminGroup but since DENY has priority the second example means "DENY nobody", i.e. ALLOW everbody. Thus the two examples are woldly different in result, but would be displayed exactly the same by TWiki:TWiki.SitePermissions

The flaw is not with the access control mechanism, it is with the way it is being communicated. The result could be misleading and dangerous. -- AA

---

This is the result of using a SEARCH to pull out the value setting rather than asking TWiki what the setting is. I originally implemented this feature using the TWiki:Plugins.TopicVarsPlugin - but was told by Peter that SEARCH was the way to go.

I believe that plugin's functionality should become part of the core and extraction of topic's variable should have its own syntax, e.g.

=%Main.WebPreferences.ALLOWWEBCHANGE%

-- MC

---

OK, this is understood, is not a bug, so I have rescoped it as an enhancement. CC

---

Y. Sorry, it started as a bug because on my install egrep was not being found so the table broke silently.

MC