Support

November 30, 2022 at 2:35 pm

Ah, ok, so you have the ticket capability requirement set to be read, edit_pages which within the code is taken literally as a single string, not 2 different capabilities.

The capability you set is for the minimum required capability, you use a single cap.

So in your example, a subscriber would have the read capability correct?

Assuming your Student role is the second one that has edit_pages, surely that would also have the read capability? Meaning your minimum required capability for both would just be simply read?

Also, what do I need to be able to differentiate two roles, one Subscriber and one Student?

So, the ticket check works on capabilities rather than roles as per the WP guidelines so you would need roles that ‘stack’ capabilities… for example:

(Role) Level 1 - (caps) level_1
Level 2 - level_1, level_2
Level 3 - level_1, level_2, level_3

Meaning if you set a min cap requirement of say level_2 then the roles ‘Level 2’ and ‘Level 3’ would be able to access that ticket as each ‘higher’ level builds on the last.

We don’t really recommend any membership plugins as they all work for different needs, but I know S2 Member ‘stack’ caps like above.

—–

Now, having said the above, the way WordPress checks capabilities does actually allow you to check based on the role, meaning adding ‘subscriber’ as a min cap would allow only the subscriber role to access it…. however, this changed within WordPress core a while back now and it is discouraged, you should check for the caps a role has (a role is simply a collection of capabilities) and may stop working if they change this later.

December 20, 2022 at 7:32 am

Yes, that text is filtered so you can use a custom snippet to change it, something like this:

https://gist.github.com/Pebblo/783dc4f9f43b9780d860112817edfd6d

December 22, 2022 at 2:51 pm

Here is an example of hiding tickets that do now have a minimum capability set on them for logged in users:

https://gist.github.com/Pebblo/16a7dabb6a6d8f0f3d4370ccda06098b

Theres 3 different functions in that gist, the first one only does the above is you have a hide_no_cap_tickets custom field set on the event.

The second does it without checking for that field but will also show ALL tickets for any users with the ‘manage_options’ capability (meaning admins).

The last one removes the tickets from view for logged in users, unless the user is a subscriber roles, in which case it displays the standard messages EE normally does.