Capabilities

The plugin does recognize custom roles, but the permissions setup is simplified to only two different kinds of access.

A developer can access and alter these permissions on a more fine-grained basis by using the ‘pdb-access_capability’ filter. Take a look at the file classes/PDb_Base.class.php, there is a function called “plugin_capability” on line 526 that processes all capability checks. You can use the “context” value to determine what capability to use, and thereby control which pages or functionality any particular user has access to.

That sounds great, thanks! I’ll check it out.

Tim

Hi again … sorry for the delay. I am looking at this now and my brain is straining to understand how this works. I am familiar with WP filters in general, but I’m trying to get my head round what exactly I need to filter for.

I’ve found this in the plugin code:

public static function plugin_capability ($cap, $context = '') {

    $capability = 'read'; // assume the lowest cap
    if (in_array($cap, array('plugin_admin_capability','record_edit_capability'))) {
      $capability = self::set_filter('access_capability', self::plugin_setting($cap), $context);
    }
    return $capability;
  }

It looks as if there are still only two choices (without editing your plugin’s code) to allocate WP capabilities to: “plugin_admin_capability” and “record_edit_capability”.

Am I right in thinking I need to create a filter in my functions.php like this:

add_filter( 'access_capability', 'rms_read_only_db_access', 10, 2 );
function rms_read_only_db_access() {
	return // something depending on context
}

I’m rather confused and an example would be great if you have time. In the meantime I shall keep trying to work this out… ??

Tim

Tim since I am looking at a permission scheme for my application. I wipped up some quick code for you. This might not be exactly what you want but should give you a better idea of how Roland uses the wp roles with pdb

add_filter('pdb-access_capability', array(__CLASS__, 'rms_read_only_db_access'), 10, 2);
function rms_read_only_db_access($cap, $context) {
  if ($context === 'edit participant' || $context === 'add participant') {
     // ** Tim you need to change the myUserCanWrite **
     if (wp_get_current_user() === 'myUserCanWrite') {
       return 'edit_others_posts'; // Users with write capabilities see: https://codex.www.ads-software.com/Roles_and_Capabilities
     } else {
       return 'read';
     }
  }

  return $cap;
}

Thank you so much, cognoquest! I am really grateful for the assistance. I think this example is going to help me get there. ??

I can see you have put my function in the context of a class – does that mean I can’t just put this code in my functions.php? I normally do my plugins as classes, but I was hoping just to put this snippet in functions.php.

I’m thinking that the context I want is “list participants”, because that’s basically the only thing I’m going to want to allow the read-only users to do. I’d like to make “view_members” the capability that allows this, so I can give this capability to any role that should have it.

So I imagine I need to do something like this:

add_filter('pdb-access_capability', array(__CLASS__, 'rms_read_only_db_access'), 10, 2);
function rms_read_only_db_access($cap, $context) {
  if ($context === 'list participants') {
     if ( current_user_can( 'view_members' ) ) {
       return 'edit_others_posts';
     } else {
       return 'read';
     }
  }

  return $cap;
}

Have I got it completely mixed up or am I on the right track?

Your welcome Tim. Yes you can put the code in the function (Note it is not recommended)

add_filter('pdb-access_capability', 'rms_read_only_db_access', 10, 2);

I think you are on the right track. I do see as an issue with your code is that edit participant is accessed via a link in the participant list

What I would do:

function rms_read_only_db_access($cap, $context) {
  if ($context === 'edit participant' || $context === 'add participant') {
    return; // Hopefully this removes the edit link inside the list and the add participant??
  }
  if (current_user_can('view_members') && $context === 'list participants') {
    return Participants_Db::plugin_setting('record_edit_capability'); // Returns to pdb the Record Edit Access Level from your Settings
  }

  return $cap;
}

You may want to exclude the admin (Plugin Admin Access Level settings) from the above process and I would add the following code at the top of the above function:

if ($cap === Participants_Db::plugin_setting('plugin_admin_capability') return $cap;

Again this is all untested code and I am not the pdb developer

Sorry I have to rethink this because pdb comes in with two access capabilities that are pre-configures in the settings i.e. Record Edit Access Level & Admin Access Level. You can not use the filter unless you are using the access configured in the pdb settings.
If you are going to create your own role capability you will have to set it in pdb as the Record Edit Access Level and code the following for your filter hook.

function rms_read_only_db_access($cap, $context) {

  if ($cap === Participants_Db::plugin_setting('record_edit_capability')  && ($context === 'edit participant' || $context === 'add participant')) {
    return 'read'; // Hopefully this removes the edit link inside the list and the add participant access ??
  } 

  return $cap;
}

Thanks again cognoquest – that is really helpful.

So basically all we can do, by the looks of things, is customise what the plugin’s “Edit” and “Admin” roles allow – we cannot add a third.

Can I therefore implore the developer – please can we have a third that is by default “viewing” access? I am convinced many others would also find this useful.

In the meantime, I will use a variation on cognoquest’s code to modify the “edit” role to a “viewing only” one, so that I can give users either “view” or “full admin”. The code above does remove most things but not the pencil, so I will see what I can do to modify that. That will do for my purposes for now, as the users in question are neither particularly tech savvy nor particularly demanding. ??

Hopefully I’ll be able to do “view”, “edit” and “full” in future. I’ll keep trying!

Tim

In fact, after a bit more looking at the code, I don’t think we can remove the pencil because it’s hard coded without a permission check. The developer assumes that anyone looking at the list will be allowed to edit. ??

I’ll have to customise the plugin itself I think…

So basically all we can do, by the looks of things, is customise what the plugin’s “Edit” and “Admin” roles allow – we cannot add a third.

Yes and no. Indeed pdb has two roles pre-configured in its settings for different purposes.

In your particular case the pdb developer uses WP add_submenu_page() to determine whether or not a page is included in the menu and it is the capability given to that function that determines the access. The second example that I provided made use of the pdb setting for your default configuration.

The first example would also have worked if you wish to completely bypass the pdb settings but you will be required to program all the user access permutations for record_edit_capability/context: main admin menu, list participants, edit participant, add participant.

Do not forget the WP capabilities is an access grid of capabilities vs roles. In other words you can return any capability for the above function add_submenu_page() to interpret.

I see what you mean.

I’ve been busy hacking the plugin to add a “record_view_capability” which seems to work with only a few lines of code changed, but I’m struggling to make the CSV export work when the user has that capability, and one or two other strange things are happening, so I really would rather use a filter as you are suggesting.

As the pencil edit icon doesn’t have a permission filter, I don’t think I can stop it appearing in the list when the user only has read permissions, but with a couple of very small hacks (of the sort I could reproduce after a plugin update if need be) I can probably make that do what I need it to…

I keep going… ??

Tim

Success – almost! I have managed to make Participants Database show records, with all filters available and CSV export as I wanted, but not allow editing. I did it by putting this in functions.php:

add_filter( 'pdb-access_capability', 'rms_read_only_db_access', 10, 2 );
function rms_read_only_db_access( $cap, $context ) {
	// If our user has the "view_members" capability and the plugin is asking
	// what permission level to use in certain contexts, tell it to use 'read'
	if ( current_user_can( 'view_members' ) && ( $context === 'main admin menu' || $context === 'list participants' || $context === 'csv export' ) ) {
		return 'read'; // i.e. allow anyone with "view_members" to do this
	}
	return $cap;
}

One challenge I still have to overcome: I need to redirect the “pencil” icon on a record to show the full record output but not to show the edit page. There doesn’t appear to be an admin-side “view record” page so I’ll have to knock one up. I’ve created admin pages before and I reckon I can do it.

Thanks again – wouldn’t have got this far without you, cognoquest.

Thanks again – wouldn’t have got this far without you, cognoquest.

Your welcome, for your last challenge, I am not sure but if your are good at css maybe you can hide the buttons on the edit form?

Something that resembles to this:

.admin_page_participants-database-edit_participant input.button-primary {

  visibility: hidden;

}

Ah yes indeed, that would be exactly what I would do except that I need the read-only users to be able to see the whole of each record, not just the visible columns in the list. So they need to be able to click to see all the fields – they just mustn’t edit them. I’m pretty confident from here on; it was the permissions setup that was mangling my brain earlier… ??