On Tue, 29 May 2007, Patrick R. Michaud wrote:
Based on responses in another thread [1], I'm of the opinion that things
will be much easier in the long run if we create a separate "Site-Admin"
group to hold strictly administrative pages. The "Site" group would
then be used to hold pages that are generally shared throughout a site.
Just as 'user case information', I also use the group Site/ to contain
more general type of information about the site. For instance, I have a
page Site.FAQ for questions about using the site etc.
The biggest difference between the two groups is that Site-Admin would
be read-restricted to admins by default, while Site would be generally
open for reading by default.
How about 'Site-ReadRestricted'?
As a result, the following pages in the core distribution would
move into the Site-Admin group:
Site.AuthUser --> Site-Admin.AuthUser
Site.AuthList --> Site-Admin.AuthList
Site.ApprovedUrls --> Site-Admin.ApprovedUrls
Site.Blocklist --> Site-Admin.Blocklist
Site.InterMap --> Site-Admin.InterMap
Site.NotifyList --> Site-Admin.NotifyList
What's the reason Site.InterMap should be read-restricted?
(The others I understand at once)
Third is the issue of migration. If adopted, we would undoubtedly end
up with a $SiteAdmin variable that identifies the group for Site-Admin
pages, analogous to the way the $SiteGroup variable works for Site
pages.
How about calling the variable '$SiteAdminGroup' (or whatever) for
consistency?
An administrator that wants to continue to use 'Site.*' for all of the
above pages can simply set $SiteAdmin to 'Site' and everything will work
as before.
I'll do it like this.
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
_______________________________________________
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
