Support

December 17, 2018 at 5:03 pm

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’).

You don’t need code for this to work.

Can it be done with code, sure, but it is not required.

Is your company available for hire to do this for us? If so, can you send us an estimate?

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.

If not, can you recommend a developer to do this for us?

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.

—-

We didn’t see the reply until now. Apologize for the delay in replying. Really wish we had a way to re-open tickets…

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?

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.

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).

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.”

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.

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.

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.

We set the role that can buy a given ticket in the field provided by EE4, such as here: https://cloudup.com/c_jZMdsd3vE

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:

current_user_can('administrator')

‘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 pmp_role_1 your checking for that role correct? It works (because WordPress)…. but it actually shouldn’t and its part of the reason this is causing confusion.

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 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).

I read in the forums that the field can also take capabilities.

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 pmpro_role_1,pmpro_role_6,pmpro_role_7 to the ticket capability field which should do what you want, but it’s the wrong way to do it from the beginning.

So before going that route, here’s how you can do it, ‘correctly’.

—–

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?

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.

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?

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.

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.

Additional role or additional capability? again they are no intechangable so you’ll need to be specific on what you actually added.

EE4 only allows the primary role of the user to buy the ticket that matches the role entered in the ticket capability field.

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.

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.

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.

December 20, 2018 at 3:52 am

We want to give you a really big, fat thank you.

You’re most welcome, I’m glad it helped.

I realize this may have been simple for you to understand, but it wasn’t until we got this explanation, step-by-step, that the light bulb went on.

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 don’t know what makes you guys so nice, but whatever it is, we’re grateful.

We are here to help 🙂