Closed andyburnsco closed 1 year ago
@andyburnsco I can't quite tease out the logic of your situation...
If user exists at the top level site, the plugin does not apply the capabilities that are added in the association role (e.g. they are not added to a Group).
Under what circumstances?
FWIW, I just tested locally and added a membership to a user who exists on the main site. I added the membership to the Contact from the CiviCRM instance on the main site. The corresponding WordPress user was successfully added to the specified Groups group on the main site. (CiviCRM WP Member Sync is network-activated)
I can see where this is an issue because if I am administrator user and my membership gets synced I don't want the plugin to override this and give me a subscriber role for instance.
Users with the admin role are excluded from sync by default. You can modify this using the civi_wp_member_sync_user_should_be_synced
filter.
However, this is where using capabilities method would give added flexibility and it could add this user to a group like 'Current Members'.
Which user exactly? Is this an admin? Or some other user? If admin, see above.
Now if a user is on a child site, the plugin does not add that user at the parent site, where all the syncing is supposed to occur.
That's expected behaviour. CiviCRM WP Member Sync should only sync between known knowns by default, and how a particular multisite is set up is subject to too many variations to accommodate them all.
You could use the civi_wp_member_sync_membership_updated
filter to customise the default behaviour. If you need a filter or action that fires before rules are applied (or indeed any other filter/actions that help you implement your specific setup) let me know.
@andyburnsco On reflection, I appreciate that this plugin maps Contacts with Memberships in CiviCRM to Users in WordPress Multisite in ways that should be better documented. Essentially, it assumes that the mapping takes place between the CiviCRM instance and its "host" site (or, more likely, sub-site). To do anything else would (in my opinion) be overstepping its remit and making assumptions about the kind of Multisite setup that this plugin is installed in. My advice above should enable you to extend the plugin to suit your setup and I'll add this info to the plugin's documentation in due course.
If user exists at the top level site, the plugin does not apply the capabilities that are added in the association role (e.g. they are not added to a Group).
Thanks, yes more documentation would clarify how to handle these use cases.
Besides the administrator exemption (which is what I was trying to do) the circumstance where it does not sync is if it is syncing to a custom user role.
You could use the civi_wp_member_sync_membership_updated filter to customise the default behaviour. If you need a filter or action that fires before rules are applied (or indeed any other filter/actions that help you implement your specific setup) let me know.
Yes, we will be in touch so we can allow users on child sites to be added as members to parent site.
My issue is on a multisite however this seems to effect single sites as there is only one wp_users table.
If user exists at the top level site, the plugin does not apply the capabilities that are added in the association role (e.g. they are not added to a Group). I can see where this is an issue because if I am administrator user and my membership gets synced I don't want the plugin to override this and give me a subscriber role for instance. However, this is where using capabilities method would give added flexibility and it could add this user to a group like 'Current Members'.
The next use case is more prevalent.
Now if a user is on a child site, the plugin does not add that user at the parent site, where all the syncing is supposed to occur.
Is there something I am missing?