Thank you, Sy. I should have thought to post to meta. I have moved it to my user page and expanded the writeup. http://meta.wikimedia.org/wiki/User:Yeidel -- Joshua On 8/30/05 8:20 AM, "Sy" <sy1234(a)gmail.com> wrote:

I think Joshua Oreman's approach gets the presentation correct (read-only page) but doesn't secure the page (e.g., against adding "action=edit" to a URL and hacking the page). Setting Title::userCan('edit') to false also causes the read-only page to be displayed without patching EditPage.php. -- Joshua On 8/30/05 11:46 AM, "Joshua Oreman" <oremanj(a)gmail.com> wrote:

Sorry, Joshua Oreman, that's a case of "Ready, Fire, Aim" on my part. I agree that the patches are essentially the same in function. Again, I haven't looked at 1.5; maybe Oreman's patch is better for that version. -- Joshua Yeidel On 8/30/05 12:18 PM, "Joshua Oreman" <oremanj(a)gmail.com> wrote:

We would like to be able to control permissions, specifically edit, of a page per namespace. While the permissions framework provides a mechanism to control permissions per group, it doesn't allow for permissions based on a resource. Specifically I would like to be able to tie a permission triple to a group, 1) permission, 2) resource, 3) allow/deny. The current model is a double, 1) permission, 2) allow/deny. I think the change would be easy, but declaring the permissions in a variable array seems messy, but I can live with that for now. The added bonus of this approach would eliminate a bunch of permission code. For example, in Title.php, this code would go away: if( NS_MEDIAWIKI == $this->mNamespace && !$wgUser->isAllowed('editinterface') ) { wfProfileOut( $fname ); return false; } And simply be replaced with the permission check. The permission structure would become: /** * Permission keys given to users in each group. * All users are implicitly in the '*' group including anonymous visitors; * logged-in users are all implicitly in the 'user' group. These will be * combined with the permissions of all groups that a given user is listed * in in the user_groups table. * * The structure of this map is <group or *><permission><resource or *> * where group is a group, permission is a permission, and resource is a resource can be on of: * 1) namespace:<namespace> * 2) .... would we support categories?... **/ I think I can hack this into the code in one place, Title.php, in function userCan. Basically, at the end of the function I would check to see if a permission is defined for this resource, and if so check the permission for that resource. I haven't yet written the code so there may well be a better place. Does this sound feasible and if so does it sound like something other want? Thanks, Dave

Sy> I think a proper permissions concept would be a great leap in Sy> mediawiki's evolution. I agree. While this isn't the Wiki Way, the Wiki Way isn't a concept that fits every project needs. I know that Wiki technology has been discussed several times and security is always the issue. Sy> Stuff to think about for a "complete" solution: Also consider having permissions set on a category basis, so that adding a page to a category applies some permissions when can then be overridden. You also need a group mechanism for different groups of users, and a permissions model for creating new pages in a given namespace, modifying, viewing, and deleting pages. Andy -- Andy Cunningham -- www.vehicle-diagnostics.co.uk Sign on door of computing lecturer: "If your project is 90% right, I will give you a distinction, your employer will fire you." -- Zebee Johnstone

Sy wrote: Without talking only about privacy, some wikis could need a permission system like that. For example, we are thinking of making a wiki for publishing and share scientific results. It's in its gestationnal step for now, but for example, we discussed the fact that when a team will publish a result, it should be that only authors from the team could modify it. If someone would ask a complementary information, or ask for something else, we think he could ask on the discussion page, and that the author would then modify the page. That's jsut an example to say that in my opinion too, it won't be bad that such a system exist. Julien

Yea, that's easy. Just put this in your LocalConfig.php $wgGroupPermissions['*' ]['edit'] = false; But his definition of a non-author could still be logged in, just not the author. In which case this solution wouldn't work. You could add all non-authors to a group and not allow that group to edit. That would work just fine, but you wouldn't have any control over authors of different cagetories/namespaces. To create a nonauthor group add this to LocalConfig.php: $wgGroupPermissions['nonauthors' ]['edit'] = false; of course this means that you'll have to set up non-authors to be in this new group and somehow prevent new accounts from getting into the authors group, etc... But that's a different topic. Dave On Thu, 2005-09-01 at 15:27 -0500, Sy wrote: -- Dave Brewster &lt;dbrewster(a)guidewire.com&gt;

Sorry, have the flu. Correct. That would be about 1,000,000 times easier. Dave On Thu, 2005-09-01 at 15:11 -0700, Hínandil wrote: -- Dave Brewster &lt;dbrewster(a)guidewire.com&gt;

Sy wrote: Not to be trite, but it sounds like what you *really* need is a content management system, which has lots of great, useful controls, and not a wiki, which has no such controls. Unless things have greatly improved since January when I was researching things, MediaWiki's the only wiki engine with a mature sense of "users" much less permissions. I humbly suggest that if you can't trust each group not to vandalize others' pages, then it might be a better investment of your time to research CMS solutions (there are some very nice Free, open source ones out there) than to try and hack around with MediaWiki which is opposed to what you want by design. Hínandil