Participants Database has two basic roles for accessing and interacting with the plugin in the backend: Plugin Admin and Record Edit. By default, these roles correspond to the WordPress roles of Administrator and Editor.
This means that if your WP role is Editor, you will be able to edit records, add new records, list records, etc. An Administrator will be able to additionally edit the configurations, delete records, perform CSV exports, and things like that.
WordPress roles are worked with at the code level by testing for a particular capability, depending on the specific context. The plugin uses two standard capabilities for determining which plugin role a particular user has. For admins, it’s ‘manage_options’ and for plugin editors, it’s ‘edit_others_posts’. So, this means that any role that has the ‘edit_others_posts’ capability will be able to edit Participants Database records.
Using Custom Roles and Capabilities
When you set up custom roles, you give those roles capabilities. These capabilities, naturally, determine what a user with one of your custom roles can do. If you want your custom role to work with Participants Database, they should have one of those standard capabilities: ‘manage_options’ for admins and ‘edit_others_posts’ for editors.
What if you don’t want your roles to have either of those standard capabilities? For that, you’ll need to define custom capabilities. This is fairly easy to do. First, determine the name of your custom capabilities, then assign those capabilities to the custom roles you’ve created.
To show you how that could work, let’s say you want to define two custom roles, and those people will mostly just be able to work with Participants Database. You would give those roles some basic capabilities (such as ‘read’), plus a custom capability that is just for Participants Database.
In this example, there are two roles: PDB Admin and PDB Editor. PDB Editor will be given the custom capability ‘edit_pdb_records,’ and the PDB Admin role will be given the custom capability ‘configure_pdb.’ You’ll give the admin ‘edit_pdb_records’ too, so that your plugin admin can do all the things.
Now, to actually implement these capabilities and use them to determine what the user can do, we need to construct a filter. The filter takes the plugin’s default capabilities for each role and changes them to our custom capabilities. Once that is done, the custom roles will have access to Participants Database in the backend.
Putting in the Filter
For those of you familiar with WordPress coding practices, you’ll know there are several ways to place the filter code. I am providing it to you in the form of a plugin (because that is the easiest for novices to use) but it could easily go into your theme functions file. If you’re a more advanced coder, you’ve got a script somewhere that defines your custom roles, and that is really the best place to put our filter so all the functions relevant to the custom roles is in the same place.
Please Note: you must have these custom capabilities in your current role. If you do not, Participants Database will disappear from the admin because it’s only visible to those with the custom roles installed by the example plugin below.
This plugin must be used with some kind of WP role editor plugin so that you can assign the custom capabilities to your roles.
Many people will be using a plugin from the WP repository to define their custom roles, so installing our filter as another plugin is a logical way to add that customization. Be sure that you are adding these custom capabilities to your roles in the role editor plugin. It won’t work without that because your roles won’t have the needed capabilities.
Here is the filter in the form of a plugin. See below the code window for instructions on how to install it.
To install, first click on the gist page link at the bottom left of the code window above. Then click on the “Download Zip File” button on the gist page, download the file, then install it using the Plugins/Add New menu item. There is a button for uploading the zip file at the top of the add new plugin page.
If you need to edit the plugin (for instance, to use different names for your custom caps) you can use the plugin file editor in the WP admin.
Additional Reading
I’ve published a couple of other tutorials on this topic, take a look at these for another look at using roles and capabilities with Participants Database.
Advanced Use of the Filter
This filter doesn’t try to change the specific things that each role can do. This is possible, however, by using the “context” value to determine which capability to return. The Backend User Access Control article above gives a list of possible contexts to filter for.
James Kersey 
Roland Barker 
Daniel 
Brian
Correct – I did just that – https://imgur.com/e3oMuaS
Only the Admin can use the link. Now the issue is that all other roles can still view it too – just as text though. The thing I was hoping was is it possible to hide that Field Group to everyone except administrators?
Thanks!
Yes, possible, but not easy because simply skipping a field in the template will mess up the layout. Really depends on the HTML you’re using. You can blank it out, but not eliminate it most likely.
Hey Roland. Am I missing something? I don’t see the filter nor the plugin download link above.
I finally got the edit record link to work but I want only Admin to see the link – not author, editor, subscriber, etc.
I an using a user and role management plugin from Memberpress https://wordpress.org/plugins/members/
I went into the Subscriber role and added the edit_pdb_records and configure_pdb and set them to deny. I then logged in as my test user (subscriber level) and can still see the link and it’s active for subscribers to edit any record.
Am I missing a step?
Roland – I got the link to work for just administrator by using the following:
<div class="pdb-field pdb-field-field->name ?>-field”>
field->title() ?>
field->name == ‘edit_link’)
{
$this->field->link = $record->get_edit_link();
}
$this->field->print_value();
?>
<div class="pdb-field pdb-field-field->name() ?> get_empty_class() ?>”>
field->title() ?>
field->print_value() ?>
Only now, the non-administrator roles can still see the link. Any way to make it invisible to all but administrator?
Not sure why but it didn’t list all of the code:
/*
<div class="pdb-field pdb-field-field->name ?>-field”>
field->title() ?>
field->name == ‘edit_link’)
{
$this->field->link = $record->get_edit_link();
}
$this->field->print_value();
?>
<div class="pdb-field pdb-field-field->name() ?> get_empty_class() ?>”>
field->title() ?>
field->print_value() ?>
*/
I’ll try linking an image of the code:
https://imgur.com/e3oMuaS
I’m not sure….this is a question for the role plugin, this has nothing to do with Participants Database access roles which only affect the backend.
The link to download the plugin is at the bottom of the code window.
https://gist.github.com/xnau/c014e27d036773269d32686c4de8b06a#file-pdb_admin_capabilities-php
Not sure I am explaining it clearly. The link doesn’t work for all non-admin – which is what I want. But, the non-admin roles can still see the link as text. Any advice?
OK, you’re going to have to build that into the custom template, it will need to check on the role of the logged-in user and add the link or not depending on their role.
Is it possible to give WP editor access to the CSV Import page in back office? Tks
Yes it’s possible, you need to add a filter that enables Editor access to this feature. This article provides an explanation and the code you need. It is for a different purpose, but it works the same way. In the example, it’s checking for the ‘delete participants’ function, in your case, you’ll be checking for the ‘upload csv’ function.
Allowing Participants Database Editors to Delete Records
Can Participant Database be configured so a custom user role can be defined so that the user ( perhaps a modified subscriber role ) can only see, edit and delete the entries that they have created but the administrator can see all user entries?
Yes, but it has nothing to do with user roles, it uses instead the ID of the logged-in user. Take a look at this article that explains in a general way how the plugin can interact with WP Users:
Using Participants Database with WordPress Users