On Sat, May 26, 2007 16:06, Patrick R. Michaud wrote: > In fact, this brings up a larger question of what to do with the > Site.* group in general... should we change the PmWiki default so that > viewing pages in the Site group is restricted to admins? There > are three options that I see: > > > Option 1: Lock the Site.* group to be read only by admins, but > unlock specific pages that need to open for reading in general: > > Site.EditForm > Site.SideBar > Site.Search > Site.PageActions > Site.PageListTemplates > Site.LocalTemplates > Site.EditQuickReference > Site.UploadQuickReference > Site.AllRecentChanges (?) > Site.Preferences > > The unlocking would be performed by having a special '@_system' > read password on the above pages (similar to '@nopass'). > > A _huge_ downside to this approach is that any recipes or skins > that provide readable pages in the Site group would need to take care > of unlocking those pages as well. > > > Option 2: Leave the Site.* group open as it is now, but lock > certain pages that should generally be restricted to admins. > This would include: > > Site.InterMap > Site.AuthUser > Site.AuthList > Site.ApprovedUrls > Site.Blocklist > Site.NotifyList > > This approach has the (big) advantage of being less intrusive for existing > sites and recipes, and there don't seem to be that many pages that need > locking. > > > Option 3: Introduce a new SiteAdmin group that contains pages > specifically intended for the site administrator. This group could > have a read password that limits viewing to the admin by default, and > the pages listed in option 2 would move to this new group. > > The downside of this approach is that it complicates upgrading a bit > in terms of moving existing Site.* pages to the new Site group, as > well as introducing a new group to the distribution. > > > At the moment I'm leaning heavily towards option 2. Any comments > or thoughts from others? >
Independent of this particular decision I would in general not to let transition considerations get too much in the way of structural decisions, cf. option 1. Though there might be adaption necessary for particular recipes, the needed changes can be clearly communicated in the pmwiki Changelogs/Release notes and usually (as in this particular case) can be expected not to make any trouble on specific sites. At the same time, favouring the structural argument often exactly avoids transition problems in the future. Concerning this particular decision I'm still very neutral. All options would lead to the most desired effect that the site admin does not have to manually adjust read-attributes once a new admin page is added to Site.* by the pmwiki engine. Option 3, which employs the paradigm that permissions are implictly set by organizing pages into respective groups, might still be the best idea _in the long run_. It has a self-documenting effect (and thus improves keeping overview over the system) -- the admin directly sees which pages are protected. With "in the long run" I mean that I would not bother keeping this for a major update. Thomas _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
