• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Bug
    • Permissions override

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Permissions override

    • Issue Tools
      • View Changes
    1. issueid=3990 September 10, 2014 9:14 PM
      delicateglow delicateglow is offline
      Junior Member
      Permissions override

      There's several issues I'd list but I think the main issue here would be if a user has additional usergroups, which some have wiki permissions set, it will conflict.
      For example. a primary usergroup has the ability to delete comments, however if the user also has an additional usergroup that doesn't have that ability, it will not grant the user access to delete comments. The primary usergroup should be overriding all other additional usergroup permissions.

      This may have caused my previous error
      https://www.vaultwiki.org/issues/3988/
      Not sure, I can't replicate it.
    Issue Details
    Issue Number 3990
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category Permissions / Security
    Status Working as Designed
    Priority 3 - Loss of Functionality
    Affected Version 4.0.0 RC 2
    Fixed Version (none)
    Milestone VaultWiki 4.0 Gold
    Software DependencyvBulletin 4.x w/ ckEditor
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. September 11, 2014 12:17 AM
      pegasus pegasus is offline
      VaultWiki Team
      Make sure the secondary usergroup is set to Not Set, or No. If a permission is set to Never, then the user will Never have permission regardless of any other usergroups. This is by design, because it is semantic with the implications of the word "Never", and it is consistent with the design of the "Never" level that is native to XenForo. This choice is available to vBulletin users because there is no reason not to make it available in both (in fact there would actually have been more development work required to remove it for vBulletin).

      However, if the user is granted permission in a primary usergroup globally, and revoked that permission in a different usergroup only for a specific area, and the primary usergroup is not also customized for the same area, then there might be a bug where the custom permissions for a different group are overriding the global permissions when viewing that specific area. By design, custom permissions should only override global permissions for the same usergroup. If there is such a bug, I don't see a way that it would affect wiki functions that only rely on global permissions (like special pages).

      Let me also stress that it doesn't matter whether the user has a group as its primary group or as a secondary group. A primary group doesn't override a secondary group. In vBulletin, all groups are given the same weight when it comes to permissions.

      If the primary usergroup is the wiki moderators group, the user will not get permissions from this group, except for areas where the user has been designated as a moderator in the Permissions > Moderators panel. Thus, simply adding users to this group will not give them permissions. You must actually define them as a moderator. This is by design.

      If the user has a user mask in Permissions > Access Masks, this will completely override their permissions from all of their user groups, except for settings with a "Not Set" value. In the case of "Not Set", it will defer to the calculated permissions based on the user's primary and secondary groups and the current area being viewed. This is by design.
      Reply Reply  
    2. September 11, 2014 12:46 AM
      delicateglow delicateglow is offline
      Junior Member
      The problem is while some users have 'X' group as their secondary usergroup, some have 'X' group as their primary, so setting some items to No/Not Set won't be ideal to some users.

      An issue I'm having is having one usergroup having the ability to delete a users comments, but also has a secondary usergroup that can't. This causes the user not to be able to delete comments.
      You can see this with the user 'Testing'. Feel free to change the password of it to access it.
      Reply Reply  
    3. September 11, 2014 10:51 AM
      pegasus pegasus is offline
      VaultWiki Team
      The user's secondary group 'Donor' has "Can soft-delete wiki comments?" set to Never. As I said earlier, this will make the user Never able to do that, even if the user is in another group that is allowed to. Instead, Not Set (No) should be used if you want the permission to be inherited from a different group the user is part of.

      In default vBulletin, there are only 2 choices for permissions: Yes and No. These have been sufficient for many years.
      In VaultWiki, these same choices are available in: Yes and Not Set (No). We use the phrase of Not Set because it more adequately describes how permissions are calculated than vBulletin's phrasing did. If you find that both together are insufficient, then likewise you find vBulletin's own Yes/No system to be insufficient, as the functionality of these two choices are consistent with the design of the choices in vBulletin.

      The calculation is actually very complicated, but in essence, on the global level, all the Yes values from all primary and secondary groups get added together. If there is anything that was not Yes, the user doesn't have permission for that.

      Never was added later in the VaultWiki Betas because we added XenForo support, and XenForo has a third option "Never", which essentially bans the user from ever being able to get that permission, unless the "Never" value is removed. Thus the way "Never" works is consistent with the design of the platform it is inherited from.

      I see you use "Never" quite a lot in your permissions. You will have to rethink this strategy, because the user will never get those permissions if they remain part of those groups.

      Since the issue in the first post seems to definitely be tied to the use of Never, and Never is working as designed, I am closing this as Working as Designed.
      Reply Reply  
    4. September 12, 2014 1:40 AM
      delicateglow delicateglow is offline
      Junior Member
      Okay, but it looks like public joinable usergroups aren't listening to "Not Set (No)".
      I have a primary usergroup (set as moderator of wiki) set to access all parts of the wiki, editing, commenting, etc. But if a usergroup has a joinable usergroup (as secondary usergroups) with all set to Not Set (No), the user with both groups wont be able to access the wiki/anything regarding the wiki. So it seems like in this case, it's sort of acting like "Never".
      Interesting thing is if a user has a primary usergroup (wiki moderator) with several joinable usergroups, changing just one joinable usergroup's permission effects all usergroups, letting me able to view the wiki.

      I pretty much have no more permissions set to "Never."


      After much testing, it seems like setting a user as the Wiki Moderator as their Primary group is causing a lot of issues.
      As it stands right now, if I make a usergroup with ONLY the group as the set wiki moderator, the user can't even access the wiki (All the permissions say "yes").
      If I change the setting of wiki moderator to a different usergroup, the user would be able to view the wiki just fine.
      If the wiki moderator group is set as a secondary usergroup, the user will be able to access the wiki.
      Is this intended?
      Reply Reply  
    5. September 12, 2014 11:02 AM
      pegasus pegasus is offline
      VaultWiki Team
      The user ONLY gains permissions from the wiki moderator group if they are defined as a moderator in Usergroups > Moderators, because the permissions only apply to the areas the user is allowed to moderate. This is by design.

      So there is no point in adding a user directly to the wiki moderator group, as it won't do anything. VaultWiki automatically adds them to the group if they are added to Usergroups > Moderators.
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 7:42 AM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.