Roles and caps not retroactively set on existing multisite blogs

[Gil Jones]

This is a fresh install of the bbpress plugin on a WP 3.2.1 multi-site. The Author role cannot see either the list of topics in the sidebar widget, or the topics themselves. All forums and topics are public.

An Author can see the forums list, access forums and sub-forums, but clicking a forum with topics will yield a page indicating the number of topics and then:

Oh bother! No topics were found here!

The Administrator confirms the topics are there. I've even globally edited all forums and topics and set status to public.

Have used the User Role Editor to add privileges to Authors to read and edit edit all posts and forums.

I had installed the User Access Manager to try to give protection to pages and posts but have uninstalled it. I fear something may be a leftover protection.

Looking at the database at one of the entries, the Post Status is "inherit" versus "publish" -- is that an issue?

---

More:
Created a new forum with one topic. Author role can now see the topic, but system says "You cannot reply to this topic." While viewing the new Forum with its list of one topic, the system says "You cannot create new topics at this time."

Have even tried boosting that user to Editor and he still cannot do anything.

The subject forums and topics were all created by Administrator.

[cnorris23]

Have you tried deactivating, then reactivating the bbPress plugin? I don't see any bbPress roles in the screenshot you posted.

[johnjamesjacoby]

I suppose it's possible that an existing site where bbPress is Network Activated could have a problem like this. The activation routine doesn't get reran on each previous site, for obvious scalability reasons. Might make sense to have some kind of diagnostics page where some of these low level things can be checked and fixed. Permalinks and capabilities are both currently invisible in the UI, and can be a source of frustration as a result.

[Gil Jones]

I have deactivated/reactivated bbPress. No change. And this is a Network Activated installation. I also deactivated the several bbPress-related plugins before reactivating.

Although the title of the ticket references Author role, the problem affects all roles other than Admin.

[captainjustice]

Additional info.
This installation of bbPress is in a networked site, and using it on a subdomain, members.daybreakrotary.us. I have not created any forums/topics on the main site.

Still more: in wp_users I (the Admin) am the only user with an entry in user_activation_key. The other users were added with a confirmation requested, but as they failed to respond, I did some adds of some of the same users without a confirmation. Could any of that explain the lack of access?

[johnjamesjacoby]

Thanks for the follow up, but it doesn't answer my specific question.

• Is bbPress network activated?
• If yes, are ALL sites effected?
• Are *some* sites affected?
• If only *some* are those sites from BEFORE bbPress was activated?
• What happens when you create a new site with bbPress active?

@captainjustice - The user_activation_key issue you mention is unrelated to this ticket, and most likely not a bbPress bug.

[Gil Jones]

Yes, network activated.

Main site shows the bbPress capabilities. Have not created and forums/topics there.

Created new site test.daybreakrotary.us and it got the capabilities.

The first sub-domain site -- the one not showing bbPress capabilities -- was created before the bbPress plugin was installed.

[Gil Jones]

Solved my immediate access problem, but not the cause, of course.

Went to main site. Used the User Role Editor plugin to modify the applicable role with the bbPress capabilities -- used the option to apply to all sites. Apparently that does in fact push through to all sites. My Author role now has access.

[johnjamesjacoby]

Thanks for the report. That's exactly what I figured was the case. Applying roles and caps retroactively to existing sites is something I hadn't planned for, but should probably happen.

[johnjamesjacoby]

See #1725 for an idea on how to approach an opt-in fix to what could be many queries and large updates.

[johnjamesjacoby]

#1725 is committed and resolves this.