Issue: Manage sidebar visibility

Since your site is fluid width, it might be that simply reducing the width of the sidebar will make your users happier. That will require some tricky CSS though, since only newer browsers will support setting a fixed width on the sidebar and leaving the article content only as fluid. And the Javascript would have to be tweaked to deal with this. I'll see what I can do for the next release.

But yes, in the Admin Panel, under Content > Sidebar Blocks, you should see a "Modify Permissions" link. Permissions are typically positive only (e.g. setting the "nowikisidebar" group to all no would have no effect if the user is a "Registered User" and the "Registered User" group has all set to yes), so it would be easier to make 1 usergroup that CAN see the sidebar, make everyone a member of it, and make it possible for users to join/leave the group.

Another thing we can consider doing in an upgrade is making a user preference for whether they want to see the sidebar, as well as saving the collapse-state between page loads.

Otherwise the only option is to remove the sidebar for everyone, by disabling the sidebar (it's in one of the setting groups -- either Aesthetics or Miscellaneous, IIRC).

I created a new joinable usergroup (permission group) with everything set to no except "is not a banned group."

When I try to set permission on this new usergroup in the wiki control panel, I get an error message "Invalid Permissions Specified." Apparently you are checking for some specific permission and generating an error if it is missing.

I have other permission groups that are already in place and I used one of them to check their permissions. VaultWiki defaults to all blocks visible, so I just joined the group for my test user. The users primary group does not see the blocks under my subject area. When I joined the group, the sidebar did not become visible.

Limited the sidebar to 300px wide in the next release. I think this should make the sidebar feel less intrusive on especially wide screens viewing sites with fluid widths.

Fixed the "Invalid Permissions Specified" in the next release. This occurs when you create a new usergroup and try to modify attachment or block permissions without setting any regular wiki usergroup permissions first.

A user with no permissions actually defaults to all No. When you edit the permissions, it shows the recommended settings for some options rather than the default. If you never save permissions for a group, even if the form showed Yes, they probably still have no permission. This behavior is confusing, so for the next release I've changed the attachment and block permissions forms to actually show the real defaults rather than some recommended values.

Fixed the problem with inheriting block permissions. You should see the sidebar now only working for users if they are in your sidebar group. The problem here was that for block and attachment permissions, only the Yes and Never values would ever work. In the interest of backwards compatibility, a missing permission translated to Yes. However, this also meant that "Not Set (No)" would never work because it would be translated as a Yes.

This is fixed in the next release by enforcing the "Not Set" value as "No" when there are no other default permissions. In order to maintain backwards compatibility, the upgrade script updates all existing permissions sets so that "existing" missing permissions (heh) are saved as Yes. Since you already have a partial fix, this would confuse the upgrade script, so you might have to update your block permissions again after the next update.

I expect to package an update this week (hoping to release some time tomorrow, but that might get pushed back).