Usergroup can edit wiki, even though "Can edit wiki articles" is set to no?

[beernuts]

We want to keep our registered users group from editing wiki articles. I have edited the usergroup and set "Can edit wiki articles" to no, but the group is still able to edit the wiki.

Are we doing something wrong?

[pegasus]

If the article was originally posted by the user you are testing with, that user will still be able to edit it as long as they have permission to edit their own posts.

If this isn't the case, you probably have Custom Forum Permissions defined for the wiki forum and that group, which will always override the default Usergroup Permissions.

[beernuts]

This was an article owned by someone else so the editing their own posts setting has no bearing.

I checked the forum permissions for the wiki root and all usergroups are set at their default permissions (Registered Users are allowed to post). Are you saying that I need to edit the forum permissions for our wiki forum and our registered users usergroup and set them to not allow them to post in the wiki forum?

If the article was originally posted by the user you are testing with, that user will still be able to edit it as long as they have permission to edit their own posts.

If this isn't the case, you probably have Custom Forum Permissions defined for the wiki forum and that group, which will always override the default Usergroup Permissions.

[beernuts]

Also, I get about 10 PHP notices when I post a reply here. Just thought you should know.

[pegasus]

It's possible permissions are just missing from cache because of a recent vBulletin upgrade or something like that. Also, if you're using vBulletin < 4.1.12, vBulletin's datastore was unstable and randomly corrupting permissions. I followed the problem for some time, and even though I never saw them mention it in release notes, the problem did go away with one of the more recent vBulletin versions. Even if you're completely up-to-date, you might try using Maintenance > General Update Tools > Rebuild Forum Information. Since bitfields are also cached, you might need to rebuild that cache, by visiting: admincp/index.php?do=buildbitfields

Are you saying that I need to edit the forum permissions for our wiki forum and our registered users usergroup and set them to not allow them to post in the wiki forum?

If you don't do this, registered users will still be able to create new wiki articles and edit the ones they started.

[beernuts]

Thanks for your reply. Just so I understand this: You're saying that even if the usergroup settings say that the group cannot edit wiki articles, if the forum permissions grant the group access to the edit wiki articles, then the group will be able to edit articles, correct?

If so, what is the point of the usergroup setting?

Not trying to be difficult. Just trying to further understand how the permissions are set up here.

Also, still getting PHP notices on this site when posting a reply: http://awesomescreenshot.com/0351584f57

It's possible permissions are just missing from cache because of a recent vBulletin upgrade or something like that. Also, if you're using vBulletin < 4.1.12, vBulletin's datastore was unstable and randomly corrupting permissions. I followed the problem for some time, and even though I never saw them mention it in release notes, the problem did go away with one of the more recent vBulletin versions. Even if you're completely up-to-date, you might try using Maintenance > General Update Tools > Rebuild Forum Information. Since bitfields are also cached, you might need to rebuild that cache, by visiting: admincp/index.php?do=buildbitfields


If you don't do this, registered users will still be able to create new wiki articles and edit the ones they started.

[pegasus]

The permissions work just like permissions do in normal (non-wiki) vBulletin forums. Usergroup Permissions are global permissions settings that apply everywhere. If custom permissions are set for a particular forum, those permissions are used instead of the global settings.

Permissions are checked as follows:

1. Default all permissions to "No".
2. Does the user have an Access Mask or Moderator Permissions for the current forum?
   
   1. If yes, use the permissions exactly as set in this Mask, and exit.
   2. If no, then 3.
3. Does the user have an Access Mask or Super-Moderator Permissions for the entire forum?
   
   1. If yes, use the permissions exactly as set in this Mask, and exit.
   2. If no, then 4.
4. For each user-group the user is in:
   
   1. Does this group have custom permissions for the current forum?
      
      1. If yes, apply the "Yes" values for the current forum.
      2. If no, does this group have custom permissions for a parent forum?
         
         1. If yes, apply the "Yes" values from the parent forum.
         2. If no, apply the "Yes" values from the group's main Usergroup Permissions.
5. If the user has more groups, repeat step 4.
6. For each infraction group the user is in (based on infraction points):
   
   1. Apply the "No" values, overwriting any conflicting "Yes" values.
7. If the user has more infraction groups, repeat step 6.

Whenever permissions don't seem to be working the way you expected, always try to ask the same questions and follow this chain.