search

christianwach / civicrm-wp-member-sync

CiviCRM WordPress Member Sync plugin keeps a WordPress user in sync with a CiviCRM membership by granting either a role or capabilities to a WordPress user who has that membership.
https://wordpress.org/plugins/civicrm-wp-member-sync/
GNU General Public License v2.0
17 stars 10 forks source link

Excluding more than admins #8

Closed kcristiano closed 9 years ago

kcristiano commented 9 years ago

In line 157 https://github.com/christianwach/civicrm-wp-member-sync/blob/master/civi-wp-ms-members.php#L157 and line 266 https://github.com/christianwach/civicrm-wp-member-sync/blob/master/civi-wp-ms-members.php#L266 You block admins from being updated via the Member sync.

I've hit a use case on a couple of clients where they have specific WP roles comprised of many capabilities to match their org structure. This occurs in many NonProfits. They have National Staff, Regional Staff, Local Staff, plus Site Admins. Each of these 'Roles' has different access to WP (Custom taxonomies, Custom Post Types, ability to publish etc) so we've created roles for them. These roles than have appropriate and different permissions in CiviCRM

Since the Site Admins must handle the changes, we use User Role Editor (Handles Multi-site better than other member/role/group plugins In my opinion) in WP and permissions in CiviCRM by Role. Handling bay capabilities (WP) and ACL's is beyond the users.

This plugin (as well as all those it is based on including mine) will happily remove a National Staff Roile if they are a member and we've set the rules to make them say a member in WP.

Right now we are checking if a user is a super-admin or if they have the delete_users cap. This exempts all admins, but not others. My thought is that we check for another cap, perhaps 'block_civi_member_sync' and if a user or role has that cap it is exempt like an admin. We'd have to decide if we want to hard code the cap and document the way to exempt a user or role from syncing or we'd add an option to the setting page where someone could add a cap to check for.

The advantage to hardcoding is usability to users after the developers/implements move on. The advantage to the option is flexibility.

What are your thoughts on this?

christianwach commented 9 years ago

Sorry for the late reply - I've been on holiday. How about I add a filter so that you can choose exactly who gets synced? You could then check for $user->has_cap( block_civi_member_sync ) and act accordingly?

kcristiano commented 9 years ago

Hope it was a great holiday.

I can use a filter, the only issue is that this basically gets taken out of the end users hands - They'd never figure this out. I do mean advanced users/CiviCRM admins. I have quite a few that are advanced and want to do it themselves. Maybe if we include an example in the readme?

christianwach commented 9 years ago

Hmm, yes, that's true. It would be a quick fix for your issue, but wouldn't have a GUI. OTOH, if there's a filter in place then you could code a plugin or extension with a GUI that could interact with the filter. That would leave this plugin relatively general in scope, whilst still allowing customisation.

kcristiano commented 9 years ago

No problem, add the filter and let me know when we can test with this. I do think that at least we can document the filter in the readme so others are aware of it.

christianwach commented 9 years ago

@kcristiano I've committed db90162f456629fd2e5af95c93a12834f0969c4d which introduces the civi_wp_member_sync_user_should_be_synced filter. I think this is in fact the right solution, because the variety of possible conditions that could exist for overriding or allowing sync is outside the scope of this plugin. Let me know if it suits your needs and I'll update the plugin in the WordPress repo and document the filter in the readme.

kcristiano commented 9 years ago

This works fine. Thanks for the changes and all the help.

christianwach commented 9 years ago

Good news. Closed via db90162f456629fd2e5af95c93a12834f0969c4d