permissions problem

**fj123** · May 15, 2016

Up til now, all of my editors have also been admins. Now I am trying to give permissions to a regular member to be able to add to and edit our wiki. I have done all of the permission changes but I end up with only two results....they can see the wiki and edit it and not see the forums or they can only see the forums but not see the wiki at all.

I cannot figure out what permissions I might have got crossed up. Heck, the whole world can see our wiki and forums, so changing permissions should NOT disable their ability to see one or the other of them.

**fj123** · May 16, 2016

Ok, I figured this out, mostly (it was a add on nav bar problem).

BUT, I do not want this new person to be able to edit any of the Index. I have unchecked those permissions yet they can still have the ability to edit the index. Is this some sort of a bug or am I overlooking some other place I need to change that also? Or something that is overriding the ability to disallow editing of the index page?

**pegasus** · May 16, 2016

Please try a more recent version of VaultWiki. The version on your site is more than a year old. We cannot provide support for end-of-life versions, especially if the issue might be resolved in a newer version.

Permissions work like this:

Start with the current wiki area (or index, if not in an area). Does the user have a permissions mask or are they a moderator? Priority occurs as follows:
a. User-level permissions mask
b. Moderator permissions mask
c. Primary usergroup and secondary usergroups

Permissions are added together. For each permission, do any of a, b, or c above:
1. Say "Never". This user is NOT allowed to do this. Skip 2 - 5.
2. Say "Yes". This user is definitely allowed to do this. Skip 3 - 5.
3. Say "No". This user is NOT allowed to do this. Skip 4 - 5.
4. Say "Not Set (No)." This user is probably not allowed to do this.
5. If this was an area or sub-area, repeat all priorities and steps for the next parent area. If the area has no parent area, repeat as if not in an area.

**fj123** · May 16, 2016

I found the problem. The changes are not saving! I am also getting this message when I save: Could not find phrase 'vw_permission_already_exist'.

I have had errors like that before, and when you first go back to the page, the changes are there. But when you go back to the page from somewhere else, the changes are not there.

How do I overcome that problem?

**fj123** · May 16, 2016

Yes, I know I need to upgrade but I just was not ready to do that right now. I always have to spend a week with the wiki after I do that and I don't have the time at the moment. I really just wanted to be able to make someone an editor, I should not have to upgrade to do something that easy.

**pegasus** · May 16, 2016

Prior to 4.0.4, it was possible to get multiple permissions entries without an error occurring. When there were multiple permissions entries, it was random which entry would be used. 4.0.4 fixed this by removing duplicates and adding safeguards against duplication.

Since you are experiencing this issue, you do need to upgrade to earliest 4.0.4 in order to fully resolve it. After upgrading, you will need to redo some permissions because only 1 duplicate entry is kept and it might not be the entry that you expected.

Even though it might be annoying, please try to keep up to date with updates, if at least to keep your web site secure: https://www.vaultwiki.org/pages/Book...tion/XSS:4-0-2

**fj123** · May 16, 2016

OK.....so as you already know, I did the upgrade. And I still have no control over the editing permissions. They are all set to no but they can still edit all of the pages now. Before it was just the index and now it is all of them.

The permissions seem to be saving just fine but they are not translating to the user.

Here is a sample snippit from the permissions.....shouldn't this setting disable the user from being able to edit the index page?

index edit.JPG

**fj123** · May 17, 2016

I was finally able to disable the ability to edit the index. Even though this usergroup is not listed as a moderator, I still had to disable all of the moderator functions. Which is sort of not intuitive to me, but then again, maybe it is.

I am still having trouble controlling what sub-areas they can edit, but the index was the big one for me and maybe if I keep playing around I will finally figure it out.

Edited to add: finally found the sub area permission problem, simply overlooked that one.

**pegasus** · May 17, 2016

I will see what I can do to improve the intuitiveness of the permissions pages. Some ideas I have:

- Link directly to the edit view for the sub-area permissions where it says "This group was customized in..."
- If it's not already possible, add an option to erase customized sub-area permissions from the edit view
- When customizing sub-area permissions, show the inherited value for Not Set. e.g. instead of Not Set (No) for everything, say "Not Set (Yes)" if it will inherit a Yes.