Method Roles: Fatal error on manual synchronization

[EventConsulting]

Clicking the button "Synchronize Now" results in the following:

Notice: Undefined property: Civi_WP_Member_Sync_Admin::$members in /wp-content/plugins/civicrm-wp-member-sync/civi-wp-ms-admin.php on line 828

Fatal error: Call to a member function sync_all() on a non-object in /wp-content/plugins/civicrm-wp-member-sync/civi-wp-ms-admin.php on line 828

[christianwach]

Thanks once again. Fixed in 431f500b0daeae30b9a17c39318fe2e1c2413c5a

[christianwach]

@EventConsulting Out of interest, why do you choose to use roles rather than capabilities? What do you do for multiple memberships? I use capabilities because WordPress handles multiple capabilities without trying to shoehorn multiple roles into it.

[EventConsulting]

Confirmed! Great, Thx!

[EventConsulting]

@christianwach I just converted CiviCRM from Drupal where we have page access based on user roles. It seemed the most easy solution. I also have multiple type members who cannot view each others content. So the "restrict_content" capability does not differentiate between the different member types to set the correct access. On the other hand there remains the issue of Drupal, able to add multiple roles to a user, and WordPress, only allowing one role to be set for a user. So currently still undecided on the best course of action ;).

[christianwach]

@EventConsulting Thanks for clarifying. It's the same issue I've run into previously. Wondered if you'd come up with an elegant solution!

I note that in the Members plugin, there are no filters to add elements to the permissions metabox that appears on posts and pages. However, there is a members_can_user_view_post filter, which passes a boolean $can_view plus $user_id and $post_id as parameters. I haven't tried this out yet, but I would guess that it would be possible to automate the access permissions through this - i.e. compare the membership of the post author with that of the viewer before passing back the modified $can_view parameter.

Just trying to plot a course into the future that'll accommodate as many use cases as possible...

[EventConsulting]

@christianwach I'm currently trying to find a solution with capabilities option and the Groups plugin. This way I can still create roles but also solve the "Membership type" differentiation through CiviCRM by having seperate capabilities set. Groups "should" allow me to give page access based on capabilities instead of user role. So allowing me to use civimember_1 directly for example.

[christianwach]

@EventConsulting I've not looked that plugin. Would be interested to learn about your experience with it.

As an addendum to previous comment: with the filter I mention, one would only have to compare the capabilities of the reader and author - since the capability granted by Membership Type will be of the form "civimember_ID", where "ID" is the numeric ID of the Membership Type. If they share a common capability of this form then allow the reader in, otherwise disallow. Or is this too cumbersome?

[EventConsulting]

This solves indeed part of it, but we also have news pages and others the admin will be posting for different selected member levels. I'm currently trying to find out if the capabilitie civimember_1 created by your plugin will be picked up by the Groups plugin for allowing access to a page.

[christianwach]

I thought it might be a bit too simplistic.

I suppose another option might be to include a custom metabox with this plugin, which would have checkboxes listing each of the Civi Membership Types by name. It wouldn't be too complex to write the page/post access code independently of the Members plugin. It might even make usage of Members redundant that way. Hmm, I'll have to try that one out.

Please let me know how you get on with the Groups plugin. It would be really useful to include in the plugin documentation if you're successful. Cheers!

[christianwach]

I'm currently trying to find out if the capabilitie civimember_1 created by your plugin will be picked up by the Groups plugin for allowing access to a page

The capabilities are not 'role caps' but 'individual caps' assigned to the specifically to the user. You may find that the Groups plugin does not pick them up.

[EventConsulting]

I just reached the same conclusion.

[christianwach]

Dang it.

What if I added some actions such as do_action( 'civicrm_cap_added', $cap ), do_action( 'civicrm_cap_removed', $cap ) etc etc? You could then map these to role caps.

Failing that, I guess using roles or the custom metabox are the only remaining options.

[EventConsulting]

That action might do the trick, but it depends on how the Groups plugin checks the access to the page (based on capability only or based on "user part of group with this capability").

[christianwach]

@EventConsulting I've just had a quick go with the Groups plugin and it seems that if you:

• add (say) civimember_1 as a capability in its interface, then
• add that cap to the field labelled "Capabilities" on the Groups options page, then
• go to a page and select civimember_1 as the "Enforce read access" capability

Then things work the way you'd expect them to, even if the user does not have membership of a group with that capability. The only "hack" is that you have to define the capability in the Groups interface. I'll have a look and see if I can make that a smoother process.

[EventConsulting]

Great, I'll try that.

[EventConsulting]

@christianwach I can confirm that the above mentioned procedure works. Perfect!

[christianwach]

@EventConsulting I've added a couple of commits which should make it easier to use the Groups plugin. The process of adding and deleting "capabilities" and "read post capabilities" is now automated; done whenever an association rule is added or deleted. Hit "Manual Sync" to update all of them in one go.

I'd appreciate a second opinion before I push to the WordPress directory repo. Thanks in advance!

[EventConsulting]

@christianwach Sorry for the delay - I have a full time job as well ;). Just tested it and I think it is working. Can't confirm it at 100% because I had all capabilities and associations already set. Deleted some capabilities & assoctiations and recreated association and the system responded as expected. Can confirm it works for me, can't confirm it would work from an empty installation since my setup has already been through a lot of configuration tests and at one point in time all capabilities and associations were already been set. This might influence my results.

[christianwach]

Deleted some capabilities & associations and recreated association and the system responded as expected.

@EventConsulting Thanks, confirms my experience.