Issue: Users can no longer edit?

I would need a link to a page, but in general, no there has not been a change that would affect ability to edit directly.

There were some changes regarding article protection -- article protection was not correctly applied in all cases in 4.0.1. It is possible that users are not able to edit protected articles now if they do not have permission to lift protection -- which is the expected behavior.

That is what comes to mind initially. Again, I would have a better idea if you linked to a page that users are unable to edit.

Users can't edit any page that they used to be able to. They can't even edit their user pages.

Obviously something changed because all we did was upgrade VW. No usergroup changes have been made.

I've looked through the changesets for the past 2 months and there have been no changes to how permissions for the Edit tab are calculated, except for a change to protection so moderators can edit articles even if the article creator says no one can (to prevent an irremovable lock). Since it sounds like your issue occurs across the whole wiki, it's unlikely this change is related.

It might just be that you need to edit a usergroup again and click save even if you don't make any changes. I don't know why but sometimes this works.

Related, I did notice that the upgrade script for 4.0.2 is supposed to "fix" permissions sets that might have been orphaned in previous versions (and were being ignored). This upgrade script does not erase any existing permissions, but rather re-applies permissions that the database forgot were already there. If you had orphaned permissions that were different from what you and your users have come to expect, you can have the behavior you experience.

You will want to look at the following types of permissions to verify you don't have renegade "No" or "Never" values in effect. The orphan fix affects the following:

• Global Usergroup permissions from VaultWiki 3 for usergroups for which you have not changed permissions since migrating to VaultWiki 4.
• User-level Access Masks that were applied to "All Areas" rather than just one area.
• Custom Moderator Permissions that were applied to "All Areas" rather than just one area.

These are the only changes I'm aware of that relate to permissions for the Edit tab in any way (there were changes to permissions for other tabs to improve security, but they should not affect Edit).

I'm aware of random memory collisions and other issues for sites using VaultWiki 4 with some builds of PHP 7 (experimental version of PHP). If you're using PHP 7, you might want to consider rolling back to PHP 5.6 until we declare full compatibility. Perhaps the memory collisions are affecting permissions.

If your issue persists, you may have to submit another Support Ticket so that we can try to figure out what happened. No one else has reported an issue like this for 4.0.2.

I don't see any "Never" permissions set anywhere, so I'm still stumped. How do we submit a private support ticket?

Use this link: https://www.vaultwiki.org/members/?d...e&productid=20

Which is available at any time under Members > Services > Free Services > Ticket Support, any time you feel a private ticket may be needed. If any fields are not applicable for your installation or you are not ready to fill them in, feel free to submit fake values for those fields for the time being.

Turned out to be a scoping problem. It resulted in some usergroups being treated as if they were the banned group. In vault/core/model/permissions/vb3.php, find:
Before it, add:
Not the case in your installation, and probably in no one's installations, but if:

• A user is not banned, AND
• A user has an ignored usergroup with "Never" permissions, AND
• The user also has an unaffected usergroup with "Yes" permissions for the same action.

This constitutes use of the "Never" permission contrary to its designed intent; however, it could possibly raise a permissions escalation vulnerability since the "Yes" on the unaffected usergroup will no longer be ignored. Note that this is not a vulnerability that users can "exploit." Thus there is no harm in leaving this issue public.

I am issuing a Patch Level release to correct this issue because there is potential for permissions escalation.