Posted: December 12, 2018 at 8:17 pm
Hello this is in response to this ticket: https://eventespresso.com/topic/one-ticket-two-roles-need-to-know-the-role-id/
We didn’t see the reply until now. Apologize for the delay in replying. Really wish we had a way to re-open tickets…
Ok, so to answer some questions, which may help with context…
Firstly, I do believe I get the difference between roles and capabilities. I’m trying to get three roles to have the capability to buy one EE4 ticket, while ‘locking’ everyone else out of buying that ticket.
I’m looking for the capability that says “you’re allowed to buy a regular member’s ticket in EE4” –> or however that’s worded. You know, like “delete posts” or “read posts” …but I want to find the capability name for buying tickets. That’s what I meant by “name.”
We already have the PM Pro user role add on that you had linked to: https://www.paidmembershipspro.com/add-ons/pmpro-roles/ You can see that here: https://cloudup.com/icLTrqlmW0T
That’s how I was able to say “we want pmpro_role_6 and pmpro_role_7 to be allowed to be pmpro_role_1 tickets.” The membership levels have already been converted to roles.
We set the role that can buy a given ticket in the field provided by EE4, such as here: https://cloudup.com/c_jZMdsd3vE
I want that field to allow 3 different user roles (which happen to be based on our membership levels) to buy that ticket.
I was looking to find out how to do that. What is the capability that allows pmpro_role_1 to buy a ticket using that field? That’s what I meant by ID.
I read in the forums that the field can also take capabilities.
But however it works, I need three roles to buy that one ticket.
Do you have a suggestion for how to do this?
I realize you said to stack it, but the problem is, I don’t know how to give the roles each the capability to buy a specific ticket. How do I give it the “A,B,C” capabilities? What is that ‘called’ in EE4, the ability to buy a an ‘exclusive’ ticket?
You’re saying buying a ticket doesn’t need to be coded. But how will the system know that only those three roles can buy that one type of ticket?
With User Role Editor plugin, we can set up capabilities per role, like here: https://cloudup.com/cn7-pTNpw1E – this can also be changed on a per-user level. And, on a per-user level, the plugin allows us to give one user 2 different roles. We could have settled for that, if it worked with EE4, but it didn’t. That’s what I meant when you asked, “What doesn’t work? What steps did you try?” In other words: I tried to give “pmpro_role_6” the additional role of “pmpro_role_1” so it could buy the same ticket as “pmpro_role_1”. But it didn’t work. EE4 only allows the primary role of the user to buy the ticket that matches the role entered in the ticket capability field.
Does this make more sense now?
This is confusing… I can admit that. But the bottom line is that I see I need to change the capabilities of pmpro_role_6 and pmpro_role_6, so they can buy pmpro_role_1 tickets. But that’s where I need your help, or the information to do that. I’m trying to find out what that capability is called, and how it can be used this way.
Thank you for your help.
You will not find one, because one does not exist. Instead, you’ll create that capability. You can name the capability whatever you want, as long as it’s unique. For example, you cannot name it
An important concept to understanding this is roles can share a common capability. For example, a WordPress “admin” role will have an “edit posts” capability, and so will a WordPress “editor” role. They both share that
WordPress also allows for adding new, custom, capabilities. So for your example, you could create a capability, name it something to the effect of
If the above isn’t a sufficient explanation, I can point you in the direction of using a plugin like S2 Members. S2 Members actually automates a lot of this by providing ready-made custom capabilities that are shared between membership roles. These are documented here:
Yes, I got all of that, and what you’re saying here confirms my original suspicion, that we need to find the capability for buying tickets, and ‘code’ it in per our conditions (you’re saying ‘create it’).
So at this point I have a few questions:
Is your company available for hire to do this for us? If so, can you send us an estimate?
If not, can you recommend a developer to do this for us?
Where should we direct a developer to find the ‘controls’ of whatever allows people to buy a ticket based on a capability, like in the existing ticket capability field (screenshot above), so it can be modified according to the conditions noted above? I’m trying to figure that part out – that’s the main missing piece I feel is important here.
Oh, just a note: we can’t really switch to S2 at this point. We invested a lot to use PM Pro, so it would work with LearnDash, which we needed it to do.
You don’t need code for this to work.
Can it be done with code, sure, but it is not required.
Generally, we don’t undertake customizations, I can check on this to confirm, however imo you don’t need custom work yet and the above appears much more complicated than it actually is.
We recommend codeable (there’s a link in the sidebar) however before doing this I really do think this can be done fairly easily, but the above reply shows theres still come overlap with roles vs caps and what/how EE is actually checking for the ticket which is why it’s getting so confusing.
I’ll break down your questions and reply, if it doesn’t help explain better I’ll check for a different method for you.
Whilst we have no plans to add a feature allowing users to re-open tickets, we can re-open and merge them, which I can do with this thread should you wish?
You may understand the difference between the two but you are using them interchangeably and that’s not going to work as expected all the time (more on this in a little).
It sounds like you have this backwards, as in you are looking for something EE is adding that says you can buy X ticket? If so that’s not how the capability check works, to explain a little…
When you add a value to this field: http://take.ms/dmBkB
EE uses current_user_can() which is a WordPress function that basically means, “check if the current user has the capability to do this”.
EE doesn’t have a hidden capability to allow you to purchase tickets, it just checks for whatever capability you set on that field on the current user, if the above function returns true, you can purchase the ticket, otherwise its false and you cant.
It’s intentionally designed this way to allow it to work in various different setups. The only thing it relies on is that you set the capability you want EE to check the user has in that field.
So there’s nothing for you to ‘find’ in EE that says you can buy this ticket, because what you set in that field is what tells EE if the ticket is available.
Great which means you PMP Roles have been added as WP roles, now what capabilities do each of those roles have? Thats the important part, it’s the capabilites on each role, not the role itself.
If you don’t know, select each of the individual roles on this page – https://cloudup.com/cn7-pTNpw1E
Then make a note of the capabilites shown for each of them.
This is why I mentioned you are using them interchangeably, your setting a role in the capability field.
It works because if you remember that current_user_can() function I mentioned earlier, it originally allowed for checks like this:
‘administrator’ is a role and not a capability assigned to the Administrator role but because someone thought that check was a good idea originally, it will return ‘true’.
So when you set the field to
I don’t know what capabilities the pmp_role_X’s have on your site, if you can list them out I’ll tell you which to use (if one is avialable across all of the 3 roles).
Again this is why there’s confusion, the field requires a capability, not a role, the fact that the role name works is just because of the above and should not be relied upon.
I said above code isn’t required for this to work and its not, but there IS a snippet that will allow you set something like
So before going that route, here’s how you can do it, ‘correctly’.
You’re using the User Role editor plugin on your site, correct?
So go to Dashboard -> User Role Editor.
Select your User role for pmp_role_1 in the dropdown at the top.
Now you’ll see a list of all the capabilites on your site and the caps for that role with have a checkbox next to them. Click on the ‘add capability’ button on the right, add a ‘member_tickets’ capability – http://take.ms/cqcOb
(You can change the cap used at a later date should you need to for now stick with ‘member_tickets’ so can run through all of this)
Now you pmp_role_1 role has that capability (select that role again and confirm it has a checkbox next to the cap, if not, click the checkbox and update).
Now select pmp_role_6 and make sure that role has that member_tickets cap.
Finally the same for pmp_role_7, make sure those 3 roles have that cap.
Now in your EE minimum ticket capability ticket field just use ‘member_tickets’ – http://take.ms/pIS2H
Log in as a member that has a pmp_role_1, pmp_role_6 and then pmp_role_7 and confirm that the users can view the tickets.
We’ve added a custom capability to those 3 roles in this setup and then we check for that capability on the ticket, as those 3 roles are the only roles we set that capability to it should only show for users on those roles.
The system know because only those 3 roles have that capability.
There are other ways to do this and it depends on how the default capabilites are set up on the pmp_roles but if you want to go down that route, I’ll need a list of the capabilties assigned to each of the 1, 6 and 7 roles to confirm.
Additional role or additional capability? again they are no intechangable so you’ll need to be specific on what you actually added.
When used as intended, the capability check gives any user with the capability you set in the ticket capability field access to that ticket, you use a single capability in that field and that single cap can be used across multiple users/roles.
We can’t just say, “You need to use capability X” because EE doesn’t add a capability for this, its just checking the capability you set on the ticket against the user logged in.
I mentioned above that there is a snippet that will pretty much do what you want to do without an additional capability, it allows you to set multiple capabilites on the ticket field and because current_user_can() returns true whe you use role names, it will work how you currentl expect it to but fair warning before you start using it, it’s the wrong way to do it and if you run into issues with it you’ll need to troubleshoot it yourself as its unsupported.
This worked for us. I hope it helps other people.
You’re most welcome, I’m glad it helped.
It wasn’t simple at first and the whole, “checking if a user can ‘administrator'” throws a spanner in the works but I’ve just gone through it enough times to follow it.
We are here to help 🙂
The support post ‘Response to’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.