Skip to:
Content

Opened 3 years ago

Last modified 3 years ago

#6154 new enhancement

tie existing role to bp_register_member_type

Reported by: youmin Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Members Keywords: needs-codex needs-patch
Cc:

Description

will this third parameter assign role to member_type? since wordpress and buddypress having predefined roles as subscriber, author, mod etc is it not possible to tie these in new api?

i tried using this function, but it does nothing.

 bp_register_member_type( 'student', array(
        'labels' => array(
            'name'          => 'Student',
            'singular_name' => 'student',
	    'role'          => 'subscriber'
        ),
    ) );
}
add_action( 'bp_init', 'bbg_register_member_types' );

Change History (3)

#1 @boonebgorges
3 years ago

  • Component changed from Roles/Capability to Members
  • Milestone changed from Awaiting Review to Future Release
  • Version 1.0 deleted

No, this is not possible. A connection between member types and roles is an interesting idea, but it needs more fleshing out than this. Can you explain the use case for having member type and role tied so closely together, so that when you change member type you also change the role? Can we imagine situations where you would want a looser association?

#2 @youmin
3 years ago

Its unfortunate situation, is their any code so that i can use at least i can tie two user roles (subscriber and author) for my project.

first of all i dont wanna let users change their roles once they (roles) selected by members, and i also dont wanna let a type of member to edit posts of their own, nor 'others posts they have to be just subscribers [eg: student role == subscribers ] and [ eg: teacher role == author ].

before BP 2.2 their were half cooked solutions for this problem, by using xprofile filed data when i heard abut v2.2 i taught this problem is gonna solve but its not unfortunately.

to do this again i have to create profile fields (these are all half cooked solutions for BP v1.5 etc there is no absolute solution for this till now. ), but if i try to do so their is no reason for me to use member types, to just show the users a extra meta box .

and also if i makes profile field [for xprofile data ] same as the member types it feels nonsense to display same meta boxes twice.

so i have only one option left either drop member types since its dont have ability to restrict certain type of user Or if their is a solution then never look back to those 'if xprofile have data thing' which old codes are not gonna work, i know that.

so i am requesting for devs to dont let this awesome piece of code in bare bones. and i also request you sir to please dont set the milestone for future release. at least provide a temporary solution.

again i am repeating ,

A Teacher can edit post can have capabilities of author, and

A student must not interfere in others work so he must be a subscriber.

and lastly if a user selects his member type its over only one time selection, then only admin can change it. if we let it open to change, their will be a mess and wrong usage of this powerfull code.

EG: for the first day a user is student, or staff then in evening he can show as he is a teacher, or doctor. isnt a joke.

and lastly sorry for my long explaination.
and expecting a solution soon.

thank you very much.

#3 @boonebgorges
3 years ago

so i am requesting for devs to dont let this awesome piece of code in bare bones.

youmin - Your use case is very specific. The version of member types being introduced in 2.2 is intended to be simple. It's not possible or practical or wise to attempt to solve every possible problem in the first version of the feature.

For the time being, there is a hook 'bp_set_member_type'. See the function https://buddypress.trac.wordpress.org/browser/trunk/src/bp-members/bp-members-functions.php#L2576. You can write your own brief function that will hook to this action, and set the appropriate WP role based on your requirements. Whether this is better or worse than the xprofile hacks you've alluded to is subject to interpretation; but it will only take about 6 lines of code to do it using the existing member type functionality, so IMO it's still worth implementing.

and i also request you sir to please dont set the milestone for future release. at least provide a temporary solution.

This is a volunteer-run project. If you have thoughts about the specifics of the implementation, please contribute. It's only through contributions that this issue will be prioritized.

first of all i dont wanna let users change their roles once they (roles) selected by members,

https://buddypress.trac.wordpress.org/ticket/6145#comment:4

Note: See TracTickets for help on using tickets.