|
Lee Collier
|
November 11, 2015 at 7:47 am
The WP Users plugin has a great deal of granularity in permissions, which is fantastic. Unfortunately, despite a number of capabilities clearly aimed at allowing non-admin users to create and edit their own events without affecting others’ there doesn’t seem to be a way to prevent users from editing others’ question groups. This is doubly difficult because a user may not be able to see the effect on another event when editing a question group.
|
|
Josh
|
November 11, 2015 at 6:19 pm
Hi Lee,
It turns out there are ways to prevent users from editing other question groups than their own. The capability system built into Event Espresso core (that’s right, EE core, not in WP users btw) was built with some extensibility by means of some wrappers:
http://developer.eventespresso.com/docs/ee-capability-system-overview/#Core_WP_Wrappers_for_user_check_functions
There’s some example code that shows how to use the wrappers to prevent one user from editing another user’s question groups in this gist:
https://gist.github.com/joshfeck/5087273c0ef4e39b13d9
You can add the above example code to a functions plugin or into your WordPress theme’s functions.php file and it can run on your site.
|
|
Lee Collier
|
November 12, 2015 at 4:55 am
Thanks, that’s fantastic. I’ve used your example and it works perfectly.
The only thing is… I’ve got users with permissions set so that they can create and manage their own events.
These users have the following capabilities:
ee_edit_system_question_groups Deny
ee_edit_system_questions Deny
ee_edit_question_group Allow
ee_edit_question_groups Allow
ee_edit_questions Allow
Following your instructions above, they now can’t edit each others’ groups, which is great, but they can still add questions to the system groups. I’ve double-checked that I haven’t given them those capabilities. Any thoughts..?
|
|
Lee Collier
|
November 12, 2015 at 5:19 am
Just to add, I’ve followed your example and added filters to do the same things for deleting and trashing questions groups, and for questions as well, and added in a custom capability so that I can still edit other people’s questions and question groups if I need to. Thanks, it’s a powerful system.
I guess I could do the same thing for the system question groups, I’m just confused as the capability names suggest that’s already built in..?
|
|
Josh
|
November 12, 2015 at 8:42 am
Yeah that should just work to not give them ee_edit_system_question_groups, it does on my test site. Can you try toggling that capability, basically grant it, the remove it to see if that makes a difference?
|
|
Lee Collier
|
November 12, 2015 at 9:41 am
Hmm that’s weird, it’s still not working. My test user has the role “author” which doesn’t have any special EE capabilities, and my customer role “event manager” which has lots of EE capabilities including those described above. I’ve toggled them grant then deny, saving each time, and I’ve logged the test account out then in again as well. I’m using the Justin Tadlock “Members” plugin. Everything else works as expected apart from this feature.
|
|
Josh
|
November 12, 2015 at 11:07 am
You might try the User Role Editor plugin. That’s the one I use and the feature works as expected when I remove that cap.
|
|
Lee Collier
|
November 12, 2015 at 12:33 pm
Hi, I’ve just tried that. It hasn’t made any difference. Looking at the capabilities spreadsheet, I can’t see any contexts for the ee_edit_system_question* capabilities – have they been implemented? https://docs.google.com/spreadsheets/d/1paQ8gdiZmIpOTJetRtk0_7GZfsWIXkioqrWmXxS4FZo/edit?pli=1#gid=20
|
|
Josh
|
November 13, 2015 at 9:09 am
The ee_edit_system_question capabilities work a bit differently in that they are filtered meta caps.
So how those work is in the case of system questions, if it’s a system question or system questions group, when ee_edit_question, or ee_edit_question_group is set in the user_can check, then the system detects it’s a system question or system question group and also checks if the user has that meta cap.
What may be happening on your site is if those cap checks are filtered, so that a different capability is checked, then the filtered cap will not be checked.
So if you can post a gist pastebin with a list of all of the caps that are assigned to the user account we can investigate further.
|
|
Omar Paloma
|
November 13, 2015 at 11:16 am
Curious. Is this (editing others questions, etc.) only an issue if granting users ee_ capabilities or is this an issue for any WP user? I ask because I have created users with no ee capability and want to minimise the chance of unintended consequences.
|
|
Lee Collier
|
November 13, 2015 at 11:55 am
Thanks, here’s the gist of permissions I’ve given to my event managers: https://gist.github.com/lpcollier/ad3a194757ac6ddf4dd3
Omar – I don’t think it’s an issue for users that have no ee_ capabilities at all. For my site, I’ve hidden the WordPress dashboard for my subscriber users and set it up to manager their registrations via the front end as I think that’s neater and more user friendly.
|
|
Josh
|
November 13, 2015 at 4:27 pm
Hi Lee,
Thanks for the list, I went and set up a user role with those caps and it’s not letting that user edit system question groups. I’m going to check with Tony first thing next week to see if he has any ideas about this. I know there’s at least one time where he was working on a plugin that would automatically set up a user role with pre-defined EE caps where he ran into something like this.
|
|
Lee Collier
|
November 16, 2015 at 4:15 am
OK I’ll look forward to hearing from you, thanks.
|
|
Lee Collier
|
November 17, 2015 at 11:53 am
Hi Josh,
Any news on this one?
Thanks,
Lee
|
|
Josh
|
November 17, 2015 at 12:51 pm
Hi Lee,
Not yet, we’ve looked into this, even set up two different sites with the same caps and can see the different results, but we haven’t found why that happens.
|
|
Josh
|
January 4, 2016 at 4:00 pm
Update: The latest release of Event Espresso 4 includes the fix.
|
