• 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
    • [4.1 Alpha 2] Add page to category no permission error

    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: [4.1 Alpha 2] Add page to category no permission error

    • Issue Tools
      • View Changes
    1. issueid=5659 February 22, 2019 2:02 PM
      ACL ACL is offline
      Regular Member
      [4.1 Alpha 2] Add page to category no permission error

      A similar looking error to issue 5654, but a different context. This time, I get the no permission error when trying to add categories to an existing page, both via the traditional ?do=edit method and also the new ?do=categorize AJAX overlay.

      I encountered this on the VW XF demo, so I don't know whether the situation is that I should not have permission but the form elements are mistakenly rendered, or, I should have permission and the error is a bug.

      I tried previewing an edit to the following page:
      Code:
      https://www.vaultwiki.org/xf-wiki/index.php?wiki/&title=Template-Line-Dropping&do=edit
      The preview works fine until I try and add a category, where an XenForo no permission overlay is shown instead of a preview.

      Viewing this page, alongside "Categories: None" is the pencil icon which will load an overlay form to add categories. I just can't save it as this too results in a no permission message.

      ----

      One other possible issue I've encountered is on the VW XF demo there is a page with a red page icon (moderated)... as a non-moderating user, should this status be visible to me?
      Code:
      https://www.vaultwiki.org/xf-wiki/index.php?wiki/&title=Image-w-Apostrophe-in-Template




      PS: I've put the URLs here in code blocks, otherwise this forum adds an extra equals sign. XF friendly URLs might workaround this E.g. xf-wiki/wiki/Title-of-wiki-page
    Issue Details
    Issue Number 5659
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category Categories
    Status Fixed
    Priority 3 - Loss of Functionality
    Affected Version 4.1.0 Alpha 2
    Fixed Version 4.1.0 Alpha 3
    Milestone (none)
    Software DependencyAny
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. February 23, 2019 12:43 PM
      pegasus pegasus is offline
      VaultWiki Team
      It would be helpful to know which demo categories you have attempted this with, since different categories might have different states (different area, protected, etc), and this could contribute or at least provide insight into the direction of the problem:
      Quote Originally Posted by ACL
      ... whether the situation is that I should not have permission but the form elements are mistakenly rendered, or, I should have permission and the error is a bug
      The specific categories are also helpful because there are multiple permissions which intersect here:
      - Permission (at the page) to add this page to categories generally
      - Permission (at the category) to add pages to that specific category
      Reply Reply  
    2. February 23, 2019 12:57 PM
      ACL ACL is offline
      Regular Member
      Good point. I experienced the permission errors when trying to add the above "Template Line Dropping" page to the category "categorieën" in Alternate Area 3
      Code:
      https://www.vaultwiki.org/xf-wiki/index.php?wiki/&title=categorie%C3%ABn&do=listing
      And then I tried creating my own category page "Big category test" in System, which went fine, but suffered the same permission issue when adding pages to it:
      Code:
      https://www.vaultwiki.org/xf-wiki/index.php?wiki/&title=Big-category-test
      I tried adding pages at least from System and Demo areas to "Big category test", all unsuccessfully.
      Reply Reply  
    3. February 23, 2019 1:49 PM
      pegasus pegasus is offline
      VaultWiki Team
      I see that your user has permissions of:
      - Page Permissions > Can add pages to categories = YES
      - Category Permissions > Can add entries to Categories = NO

      So the page would not prevent you from putting it into a category, but no categories will accept that. So the correct behavior would be that you cannot add content to categories.

      So at first glance, it looks like the error message is correct.
      Now we have different questions:

      Should you be able to see the category editor? If you have custom permissions for another area where the second permission is on, then yes, because you would be able to add to categories that exist in the other area. If you don't, but if you have permission to remove existing listings from categories (you DO have: Category Permissions > Can remove entries from Categories = YES), then you would see the category editor.

      Since you don't have add permissions from the category side, the editor should not be offering those categories as add-choices. I believe this is the bug we are seeing.

      Now if there are no areas that would have categories accept new listings from you, but there are categories allowing you to remove existing listings, then I think the design of the editor needs to be improved, because it does not currently make a distinction here, and that is another issue that should be corrected. In this (your) case, the category editor should still show, but it should not provide any controls allowing you to add new categories -- only the current/remove sections should be shown.
      Reply Reply  
    4. February 23, 2019 2:29 PM
      ACL ACL is offline
      Regular Member
      Thanks for the reply.
      Quote Originally Posted by pegasus
      Since you don't have add permissions from the category side, the editor should not be offering those categories as add-choices. I believe this is the bug we are seeing.
      Right, there's not much point suggesting the categories where user permissions wouldn't allow the add entries action.

      Quote Originally Posted by pegasus
      Now if there are no areas that would have categories accept new listings from you, but there are categories allowing you to remove existing listings, [...] the category editor should still show, but it should not provide any controls allowing you to add new categories -- only the current/remove sections should be shown.
      I see, I think that sounds right. Having the form adapt to the user permission combination (add entries YES/NO & remove entries YES/NO) would be an improvement, for sure. But there could be a further improvement, too. In a situation where a user would only have the ability to remove a page from a category but not add, if the page isn't listed in any categories currently, then the AJAX form pencil edit button next to "Categories: None" would be unnecessary.

      ---

      One other potential improvement here, long term, could be during new category creation itself. It would be a reasonable assumption that someone making a new category probably intends on attaching pages to it at some point . I don't remember seeing any warning/notice while creating "Big category test" in the VW XF demo System area that my permission combination wouldn't allow adding pages to it. While I'm not suggesting that new category creation should be blocked, having some kind of indicator of suitable Areas might be good.
      Reply Reply  
    5. February 25, 2019 2:48 PM
      pegasus pegasus is offline
      VaultWiki Team
      The following should be fixed in the next build:
      - When the user has permission to view a page that has moderated edits but does not have permission to view moderated edits, the page's status icon uses the moderated color. In the next build, the icon will instead use the appropriate new/old color for those users.

      Assuming the following condition:
      The user has no permission to add listings to any categories and; the page has no categories or the user has no permission to remove listings from any categories.

      The following should be fixed in the next build:
      - Don't show category editor or its pencil icon.
      - When attempting to access do=categorize, throw a permission error.
      - For the category editor's New Category button, only offer areas where the user has permission to also add listings to categories.
      - For choosers for other container-types (books, feeds, etc), the New [Container] button has similarly been fixed so that only areas where the user has permission to also add to the container are offered.

      In the next release:
      - If the category editor still appears, don't show the add-category portion of the category editor when the user has no permission to add listings to any categories.
      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 3:46 PM.
    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 © 2025 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.
    Copyright © 2008 - 2024 VaultWiki Team, Cracked Egg Studios, LLC.