Tech comments:Acegi Upgrade

[Edit]User/Group permissions

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

Did this actually happen? If so what exactly was implemented?

I would just love to use the user/permission system from leading forum software like vBulletin, PHPBB, IPB, etc.

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.

[Edit]Delete Role

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

Deleting users is currently unsupported in JAMWiki as it would affect edit history and other functionality (Basically: every edit is attached to a user or IP. Deleting a user breaks that relationship). Would it be sufficient to allow accounts to be disabled so that the users in question could no longer login and wouldn't show up on Special:Listusers? -- Ryan • (comments) • 15-Apr-2009 07:55 PDT

[Edit]ACL

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),

PLEASE PLEASE PLEASE don't use disastrous "WikiWords" to name the permissions. Put these in a namespace properly, like project:style_sheet, project:bottom_display_area and project:top_display_area. And for God's sake do NOT use WikiWords in the names of permissions, use sane readable English language phrases separated by underscores, which is the reason Wikipedia is big and other wikis never are.

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.

I'd just like to second this as a feature I'd like. Particularly to have a privilege that allowed editing of pages Oliver 13-Oct-2006 08:09 PDT

This will probably end up being the first feature worked on for 0.5.0 - it's long overdue. -- Ryan 13-Oct-2006 11:58 PDT

It's very difficult to do right. Interaction with multiple virtual wikis, with categories and namespaces, need to be thought through and designed, not arise by accident.

[Edit]integration with Apache?

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."

[Edit]NO fine-grained permissions - contrary position

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:

• they interfere with collaboration by removing the assumption that everyone can edit every page, people can no longer ask each other to do things for themselves if there are many pages that those asked may not be allowed to edit
• they could interfere with a publishing mechanism (which would probably be blog-like) that would have its own permissions scheme requirements
• they would be redundant with existing web-server-based permissions and probably interfere with those too

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?

[Edit]at least make them really easy to turn off post-facto when they get screwed up

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.

[Edit]captcha and solve-this are permission levels

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.

[Edit]Status Update

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