[Resolved] WooCommerce Subscriptions and Access have a multiple-roles problem

[Author]

Posts

[Jerry Hudgins]

At the end of your tutorial for using WooCommerce Subscriptions and Access together:

https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/

you state the following:

"After filling in all the WooCommerce fields on the checkout page a new user account will be created with the Customer role (a WooCommerce role). Once the customer order is marked as completed, the user role will automatically change to the role you had chosen in the Subscriber Default Role."

However, at least using the current WooCommerce 3.4.3 and WooCommerce Subscriptions 2.3.2 plugins, this isn't the case. The Customer role is indeed applied upon order completion, but Subscriptions doesn't replace Customer with the Subscriber Default Role; rather, it adds it, so that the account will have both roles.

Various existing threads, including these:

https://toolset.com/forums/topic/membership-access-allowing-multiple-roles-memberships-per-user/
https://toolset.com/forums/topic/multiple-roles/
https://toolset.com/forums/topic/multiple-access-roles/
https://toolset.com/forums/topic/need-to-assign-2-roles-to-users-and-limit-access/

have noted that the Access plugin does not properly handle multiple roles per user. That indeed appears to be true, as could be seen when I set up a membership site using a custom role created by Access as the Subscriber Default Role for the Subscriptions plugin. The custom role ("Member") conferred read access rights to a custom post type ("Member Page"). This worked as intended when I manually changed an account's default "Subscriber" role to "Member" and back. However, when Subscriptions adds "Member" in addition to the "Customer" role supplied by WooCommerce core, the account in question does *not* have read access to the CPT. Using the "Multiple Roles" plugin to create this situation manually, I can reproduce the effect. If "Member" is the only role, it works fine; if "Customer" is also present, it does not.

While I haven't looked at the Access code to verify this, the behavior observed suggests that a logical AND of the Access read permission settings for each role is performed, rather than the expected OR. Based on this assumption, I found a workaround for this particular situation: I enabled the Access read permission to the CPT for the "Customer" role as well, and then configured Subscriptions to use the default "Subscriber" role as the Inactive Subscriber Role. ANDing Member and Customer roles then permits read access to "Member Pages", but an expired subscription with Customer and Subscriber roles is denied access, as intended. Please let me know if I'm making an invalid assumption about how Access works and am likely run into unexpected trouble with this approach.

This workaround is awkward and certainly doesn't scale well to more complicated situations. Shouldn't Access use a logical OR for its access bits, so that roles can independently confer specific access? I would certainly urge you to consider this change, especially given how WooCommerce Subscriptions operates.

In any case, the tutorial referenced above should be updated to address this issue.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Well - The main issue that Access supports single role at the moment is known, actually its not a issue but how Access is designed to work for now.

The feature to allow support for multiple roles with Access plugin is already with our Devs todo list and they are going to rewrite the Access plugin soon so that users will use this feature with multiple roles support per user. However, Please note that there is no ETA on it but this is something we are looking to implement with Access plugins really soon.

For now, when we get such queries, users are using either standard hook or workaround so that they will update the user role according to their need using standard WooCommerce Hook or either using some other custom workaround.

The workaround you shared is awkward as you admit but you should use the workaround shared with the following link that will change the role for user. Please check following code snippet:
=> hidden link

[Agnes Bury]

Hello Jerry,
this is Agnes Bury, the author of this tutorial
https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/how-to-use-the-woocommerce-subscriptions-plugin-with-toolset/

Thank you for your detailed description. I'll be happy to update the tutorial as you suggested but there is one thing I'm not sure about. You say "Based on this assumption, I found a workaround for this particular situation: I enabled the Access read permission to the CPT for the "Customer" role as well,"

By default, for a new custom post type, the Customer role has the read permission. Please see my screenshot attached. Why did you need to enable it?

[Jerry Hudgins]

Minesh: Thank you for the update on the status of the Access redesign, and for the reference to the hook that updates the "Customer" role. I may leave the current workaround in place in this instance, but if I run into more complex situations before Access supports multiple roles, it could be a useful alternative.

Agnes: Thanks for the tutorial, which I found clear and useful. As you say, read access to the CPT was initially enabled for the Customer role. Leaving it enabled for a restricted-access CPT was not at all intuitive for me, and I think I'd have a lot of company in that. If this site also sold a tangible product, that purchase would also confer read access without any subscription having been purchased, clearly not the intent. I cleared the read permission bit for Customer (as well as Author, Contributor, Subscriber and Guest) based on the fact that I didn't want those roles to confer read access. However, the apparent AND-ing rather than OR-ing of permission bits from multiple roles performed by Access at present made it necessary to re-enable the permission for Customer. In my situation, that's a workable (if unobvious) approach. It wouldn't necessarily work with a more complex mix of products. I think that the multiple-role issue with Subscriptions should be mentioned in the tutorial, perhaps with a pointer to the hook that Minesh mentioned as another workaround.