Moved from Feature Requests:
"The 0.6.0 release WILL offer fine-grained permissions, allowing a site administrator more control over limiting what users are allowed to do -- see Tech:User Permissions. I'm hopeful that the release will happen before the end of the month." Ryan 10-Aug-2007 19:14 PDT
Holger Engels proposed "a permission for every item (function/ data) worth protecting. Permissions can then be bundled as Roles (i.e. nobody, user, admin, ...) and Roles can be assigned to Users. This is more flexible, because then one can freely define new roles."
Use cases should be raised in Tech:User Permissions where several already exist. Detailed discussion of use of roles, integration with multiple virtual wikis, categories and namespaces also belong on that page.
Add ability to allow administrators to delete roles. Currently you can only create or edit. Note: this request may be superseded by planned ACL changes.
Hi, I have created a lot of user accounts to login. But, I don't see any option (even I login with admin ID) to delete any user. Do I need to delete manually the user details from Database? Or Is there any other Option do so...Plz help me.... Venkat
Longer term goal is to implement an ACL-based permission scheme allowing various Wiki actions to be assigned to users or groups. This is an extremely complex feature that can very easily be abused, and many exploits are possible to defeat such systems.
It's likely to be a classic ACL system - an admin defines a group consisting of users and (possibly) sub-groups. There will then be a series of actions that can be assigned to one or more group. For example, there might be a translator action (access to Special:Translation), a web design action (access to StyleSheet, BottomArea, TopArea),
a site admin (ability to delete pages, make pages read-only, etc), a sysadmin (access to Special:Admin), etc. The tricky part will be implementing this in a way that is/could be compatible with existing LDAP solutions, and also doing it in a way that doesn't kill performance.
Users who "want to restrict the write-access to authenticated and approved users" such as Tom should use apache passwords on "edit" URLs. Within jamwiki Ryan says they "can currently prevent non-logged in users from editing by selecting the "Force setting of username" option from Special:Admin - that label isn't very clear for the checkbox's purpose and will probably be changed for the next release."
There is a contrary position that deserves representation as it may influence some aspects of implementing this, and at least prevent the worst errors and misfeatures.
Fine-grained permissions in the wiki itself have several serious problems:
Until how the interaction with the web server, a publishing/blog mechanism and the social patterns of the wiki is clearer, implementing gACL should be put off. Apache integration needs to be very carefully thought through, as does multiple virtual wiki integration. Then namespaces. Then categories. Only when the implications of permissions associated with all of these is a lot clearer, should a separate permissions system per page start to evolve.
Intellipedia, the US intelligence community's massive mediawiki, don't use or need fine-grained permissions. They rely on perimeter protections and the web server. If that works for them, why not for everyone else?
At the very least all fine-grained permissions must be able to be turned off post-facto with one click in the configuration. They are almost always so badly designed that they destroy any chance of collaboration and even very experienced administrators often have to redo them every few years or so.
A captcha or solve-this-number-puzzle utility is also required because spam filters are hard to configure and often problematic. It needs to be integrated with the permissions system since "allow edit with captcha" is a permission level. It's also a mediawiki extension.
Even if there's no other permission system, this needs to be supported.
JAMWiki 0.6.0 introduced a basic user permission system. It is undergoing additional enhancements, and may be significantly modified once the next major version of Acegi is released. -- Ryan 23-Mar-2008 10:37 PDT