I am trying to add to the main site of my BP installation four more roles, which would have the same capabilities as default BP subscriber (another crazy idea).
There are several plugins to achieve this, as I see, at the moment best one is (however it does not have default role for super admin):
The issue is that I can not find list of roles capabilities for the default BP installation. I mean superadmin can do….., author…., subscriber… and so on.
Are roles in BP the same as WP?
If I have multisite activated, do I need to search for some WPMU roles?
Roles and capabilities are a WP factor not BP, as far as I’m aware BP does not create any roles or specific capabilities.
If you want a good role manager plugin I would suggest Justin Tadlock’s one ‘Members’ however ‘capsman’ may well suit your requirements.
“as far as I’m aware BP does not create any roles or specific capabilities.”
Except for Groups and Forums where users can be given more roles.
With the limited exception of BP groups, BuddyPress offers only one role — that of user. The forums are controlled by bbPress code, integrated into BuddyPress, but it’s bbPress that is in control of offering additional roles. Even when bbPress is relaunched as a WordPress plugin, forum roles will still be controlled by bbPress.
BuddyPress is a social layer that sits on top of WordPress. As such, the notion of user and author are synonymous. What does all of this mean?
With the exception for BP groups mentioned above, BuddyPress is a user-centric platform where there are currently no-jointly owned or controlled subsets of data. Ignoring the overall Site Administrator, in BuddyPress, there is a one-to-one relationship between a given piece of datum and a single owner of that datum. The key is who owns data. That person is the one with ultimate control (ignoring the super admin). Even with groups, the original group creator is the owner of the group–at least until he or she adds another admin. Group mods do not own the group data, they just help to manage it. Now, if the original group admin leaves the group, the new admin becomes the sole owner.
So user roles are irrelevant to the operation of BuddyPress as it focuses on users and not user roles. It is a social networking layer after all and not a content authoring and management layer like WordPress.
“Except for Groups and Forums where users can be given more roles.”
to clarify – this is internal buddypress “roles” (group admin/mod) not plugging into wp_cap/roles
yep groups and forums are not roles in the strict sense of WP roles and capabilities, which is what I guess I meant in my initial comment.
For BP 1.3, we’re going to add current_user_can checks throughout so if someone wanted to add a capability to a certain role or user, they could.
Already doing that personally, you can run a check on current_user_can to see what capability they have. Roles and capabilities are handed down to all users regardless by WP or am I missing the point?
“For BP 1.3, we’re going to add current_user_can checks throughout so if someone wanted to add a capability to a certain role or user, they could.”
Providing that flexibility is nice. However, with the exception of groups, there is no reason that the current BP core components need to offer the ability to assign roles. Why would a user want to grant someone the right to control their personal content? Facebook and Twitter don’t offer users that option.
Blogs, which live outside of BuddyPress, are different of course. It makes sense to allow blog owners the ability to add helpers to their blog, to allow others to add content as authors or editors, etcetera. In BuddyPress, this type of collaboration is also currently possible with the group component.
But for all other core components, assigning additional roles seems like a bad idea as the focus is on individual users creating their own content which they alone control.
“If I have multisite activated, do I need to search for some WPMU roles?”
MNope. They are the same, with one extra: Super Admin. They can do anything.
“Providing that flexibility is nice. However, with the exception of groups, there is no reason that the current BP core components need to offer the ability to assign roles. Why would a user want to grant someone the right to control their personal content? Facebook and Twitter don’t offer users that option.” — Jeff Sayre
Hi Jeff, sorry to reopen this topic, but I think it needs a revisiting.
The ability to easily hook into wp user capabilities and extend them to buddypress user capabilities is useful in several social network contexts. And, I hope buddypress is trying to be a more flexible platform than facebook or twitter since it is an open source platform that developers would like to be robust and scalable. I understand the idea of an egalitarian social network like facebook, etc. However, there are many social contexts in which a hierarchical social network structure might be needed. Furthermore, adding the flexibility to developers as an additional component of buddypress would not complicate it’s egalitarian default settings.
One example of a hierarchical context is an educational institution with Administrators, Professors, Instructors, Teaching Assistants, Students, Prospective Students, Alumni, etc.:
As it is now, there are only bbPress roles within groups (which are needed). However, without the ability to assign capabilities within buddypress outside the scope of groups, it is nearly impossible to create capabilities restrictions such as:
user_may_delete_comment (e.g. spam or inappropriate comments)
and so on.
In particular, the ability to restrict certain users from creating groups has been a topic in many other forums about buddypress. Yet, it hasn’t been well addressed.
Here’s a little bump of requests, and reasons for added user capability management and/or user roles in buddypress. Sorry for the list, but it seems like there is some resistance in the BP community to doing this, while there are many requests for it.
This couldn’t be done without user roles:
Because clearly you won’t want to all anybody to make a group “sticky”
A recommendation to hack buddypress to create roles:
Crazy use of multiple wp plugins to create user roles for bp, with no success:
End of this thread about restricting group creation
Another shaky attempt to restrict group creation
Unanswered request for user capabilities management admin
Another request not answered:
@Jeff. We are in desperate need of limiting roles of users on BP. We are operating in a K-12 environment with students and teachers. Can we limit the roles of local users (students)? We just upgraded to WP3.1 and the new BP as well.
Fitz, LMS’s would be yet another good purpose for roles in buddypress. Not sure why we’re not getting a response here. Seems like a big issue.
Sorry to sort of bump into a somewhat old topic, but I would like to add that I am also in the need to control user roles in BP. I am using BP for a client who only wants to allow advanced profiles for users with paid memberships. If there’s currently any way I can achieve this, I would really appreciate if anyone gave me a hint towards said solution.
@larrysmith1000, @Arwym, @FitzUCF, @janismo, @hnla
I don’t know if anyone is still looking at this, but I think it is a topic that is worth pursuing. What seems to be getting lost though is what it takes to do the job.
A facility like Justin Tadlock’s members plugin is a big help. It provides a mechanism to define and edit roles and apply them to users. That covers a lot of territory. However, unless the content management part of the software looks for and enforces those roles, it is meaningless. Justin provides a facility to do that if what you are talking about posts/pages and potentially custom post types. That is fine for WP content or even things like BuddyPress Docs where Boone implemented it as a custom content type (although I haven’t look at the details of his implementation relative to permissions). However, BP adds additional content types. And it is not just FORUMS. Groups are a content type. Private messaging is a content type. etc.
That is where the current_user_can() checks make sense. Users should have permission to perform actions. That doesn’t necessarily mean new roles, but it does mean distinct capabilities. Those capabilities can then be assigned to any role that makes sense. But the capability list needs to be published like it is for WP http://codex.wordpress.org/Roles_and_Capabilities
The mechanism for assigning capabilities to roles and roles to users and doing the actual check is all WP. It’s already there. Justin provides UI to access it. What I am seeing missing in BP is published string literals that have meaning in terms of capability sets and I assume the current_user_can() checks that actually make it happen. (I looked for it on Google and this is where I was directed!)
@DJPaul you talked here in terms of BP1.3, which is now 1.5 I believe. Did any of this actually make it into the code? If not, it sure would make sense to me to find it’s way on to a revised RoadMap.
My 2 cents!
Bump. I agree it should at the least make its way onto a Roadmap. If I’m understanding this correctly, there is no unified user-management system in the code base itself. I know I’m significantly hacking a number of Buddypress features to work around this issue in two of my current projects, and it seems like this missing functionality is a barrier to BuddyPress’s evolution.
I needed to restrict which user could “Create a Group” in my WordPress 3.3.1 and BuddyPress 22.214.171.124 installation. I was able to do this easily by using these 3 plugins:
BuddyPress Restrict Group Creation (http://wordpress.org/extend/plugins/buddypress-restrict-group-creation/)
User Role Editor (http://www.shinephp.com/user-role-editor-wordpress-plugin/)
For example, I wanted to allow only an “s2Member Level 4″ member to have the ability to create new Groups. I did the following:
1. Added user capability “publish_posts” as a new rule to the Restrict Group Creation settings.
2. Selected the role “s2Member Level 4″ and added the “publish_posts” capability in the User Role Editor settings.
Thereafter, the “Create a Group” button only showed up for members who were s2Member Level 4. The button also showed up for Authors, Editors, and Administrators…but that could easily be controlled by changing the rule in Restrict Group Creation.
You must be logged in to reply to this topic.