group_management_remove_group_leader_permission

Description

Usage

add_filter( 'group_management_remove_group_leader_permission', 'your_function_name', 10, 1 );

Return Value

The filtered value.

Examples

/**
 * Example of how to modify the permission required to remove a group leader.
 *
 * By default, users with the 'group_leader' capability, 'manage_options' capability,
 * or 'ulgm_group_management' capability can remove group leaders. This filter allows
 * you to add or change the capabilities required.
 *
 * @param string $permission The current permission string.
 * @return string The modified permission string.
 */
add_filter( 'group_management_remove_group_leader_permission', 'my_custom_group_leader_remove_permission', 10, 1 );

function my_custom_group_leader_remove_permission( $permission ) {
	// In this example, we're adding an additional capability requirement:
	// 'edit_others_groups'. This means a user must have EITHER the original
	// permissions OR the 'edit_others_groups' capability.
	//
	// If you wanted to *replace* the default permissions, you would simply
	// return an array of capabilities:
	// return array( 'edit_others_groups', 'some_other_capability' );
	//
	// However, the current implementation expects a single capability string
	// for current_user_can(). So, if you want to check for multiple capabilities,
	// you'd need to adjust the 'if' condition in the source code itself to
	// handle an array of permissions.
	//
	// For this example, we'll assume the original logic is meant to check against
	// a single capability string and we're adding a new one that *also* grants permission.
	// The source code checks:
	// ! current_user_can( $permission ) && ! current_user_can( 'manage_options' ) && ! current_user_can( 'ulgm_group_management' )
	//
	// If we return 'group_leader', it checks for that. If we return 'custom_leader_manager',
	// it checks for that.
	//
	// A more flexible approach would be to return an array of capabilities and
	// adjust the `current_user_can()` checks in the plugin's source to iterate
	// through the array.
	//
	// For the sake of demonstrating a realistic filter that works with the *current*
	// source code structure, we can either modify the string that `current_user_can()`
	// checks, or rely on the subsequent checks for 'manage_options' and 'ulgm_group_management'.
	//
	// Let's assume you want to add a new, more specific capability for managing
	// group leaders, but still allow existing ones. The source code already has
	// fallback checks for 'manage_options' and 'ulgm_group_management'.
	//
	// If you want to require a *specific* custom capability to be checked first,
	// you could do this:
	// return 'custom_group_leader_management_permission';
	//
	// And then the source code would check:
	// if ( ! current_user_can( 'custom_group_leader_management_permission' ) && ! current_user_can( 'manage_options' ) && ! current_user_can( 'ulgm_group_management' ) ) { ... }
	//
	// The most common scenario is to *add* to the list of allowed roles/capabilities.
	// Since the `apply_filters` is done once with 'group_leader', and then `current_user_can`
	// is called multiple times, a simple string return here would *replace* the 'group_leader'
	// check with whatever you return.
	//
	// To truly *add* a permission without modifying the plugin's core logic significantly,
	// you'd typically want to check for multiple capabilities within your filter callback
	// and modify the `$permission` variable if an additional permission is found.
	// However, the source code only uses `$permission` once in `current_user_can()`.
	//
	// Given the structure, the most practical way to "add" a permission is to
	// rely on the fact that the original 'group_leader' is passed and subsequent
	// checks for 'manage_options' and 'ulgm_group_management' exist.
	//
	// If you want to *enforce* a new specific role, you would return that role.
	// For demonstration, let's say we want to add a new role 'ultimate_group_manager'
	// that grants this permission. The source code would then check:
	//
	// if ( ! current_user_can( 'ultimate_group_manager' ) && ! current_user_can( 'manage_options' ) && ! current_user_can( 'ulgm_group_management' ) ) { ... }
	//
	// And the original 'group_leader' check would be skipped because we're returning a new string.
	// This is the most straightforward interpretation given the single `$permission` usage.
	//
	// If the intention is for the user to have ANY of a list of permissions, the source
	// code would need to be adjusted to handle an array return.

	// For this realistic example, we'll define a new custom capability
	// that grants permission to remove group leaders.
	// The source code will then check for this new capability *first*.
	// If the user doesn't have this new capability, it will fall back to
	// checking for 'manage_options' and 'ulgm_group_management'.
	// The original 'group_leader' check will be superseded by the return value here.
	$custom_permission = 'custom_ultimate_group_leader_manager';

	// If you have a specific role in mind that should grant this, return that role slug.
	// For example, if you registered a role 'group_administrator' with add_role().
	// return 'group_administrator';

	// In this example, we return a new capability slug.
	// The plugin's code will then check if the current user can perform this action.
	return $custom_permission;
}

Placement

This code should be placed in the functions.php file of your active theme, a custom plugin, or using a code snippets plugin.

Source Code

src/classes/helpers/rest-api-end-points.php:1398

// Was an action received, and is the actions allowed
		if ( empty( $request->has_param( 'action' ) ) || ! in_array( $request->get_param( 'action' ), $permitted_actions, true ) ) {
			$data['message'] = __( 'Select an action.', 'uncanny-learndash-groups' );
			wp_send_json_error( $data );
		}

		// Does the current user have permission
		$permission = apply_filters( 'group_management_remove_group_leader_permission', 'group_leader' );
		if ( ! current_user_can( $permission ) && ! current_user_can( 'manage_options' ) && ! current_user_can( 'ulgm_group_management' ) ) {
			$data['message'] = __( 'You do not have permission to remove groups leaders.', 'uncanny-learndash-groups' );
			wp_send_json_error( $data );
		}
		$users = explode( ',', $request->get_param( 'removing-group-leaders' ) );
		$users = array_map( 'intval', $users );

Related Hooks

• ulgm_group_leader_added — fires_nearby