feat(group-subscriptions): handle group subscription members

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

This PR adds the business logic for associating user IDs with a group subscription as group members, as well as getting the members for a given subscription and the group subscriptions for a given user ID. It also adds a feature missing from NPPD-1037, to allow admins to directly edit the members of any group subscription, which should aid in testing for this PR.

The UI in the subscription admin pages now perform operations via REST API instead of requiring

The logic to control content restriction by group subscription membership, as well as UI for group owners to invite and manage group members, will come in future PRs.

Closes NPPD-1119 and NPPD-1040.

How to test the changes in this Pull Request:

1. Check out this branch.
2. As an admin, edit an existing active subscription.
3. If not already enabled, check the "Group subscription enabled" checkbox. (Note that this checkbox and the "limit" field are currently saved upon saving the subscription, not when interacting with their UI elements. However, the "enabled" setting is automatically turned on when calling Group_Subscription::update_members() to support the admin flow of enabling the checkbox and immediately adding new members.)
4. Confirm that there's a new "Add new group members" autocomplete field that's only visible when "Group subscription enabled" is checked.

5. Type a user search term in the "Add new group members" field. Confirm that the autocomplete suggests matching reader users (customer and subscriber roles by default), excluding the subscription purchaser (manager) and existing group members.
6. Select one or more readers and confirm they're added to the "Group members" list. Save the subscription and confirm that the changes persist after a refresh.
7. Add more readers and remove other existing ones. Confirm that these changes also persist after page reload.
8. If you add more members than the defined "limit" setting, confirm that you see an error:

9. Increase the limit field and save, then confirm that you can add more members up to but not past the new limit.
10. Using wp shell, test the new utility methods which will lay the groundwork for future Group Subscription features:

> Newspack\Group_Subscription::is_group_subscription( $subscription_id );
= true // True if group subscription enabled for this sub

> Newspack\Group_Subscription::get_managers( $subscription_id );
// Array containing just the purchaser's user ID (this is an array so that we can more easily add features to allow multiple group managers per subscription in the future if we need to)
= [
    528,
  ]

> Newspack\Group_Subscription::get_members( $subscription_id );
// Array containing user IDs of all group members
= [
    419,
    96,
  ]

> Newspack\Group_Subscription::user_can_access( $user_id, $subscription_id );
= true // True if user is a member or owner of the group subscription

> Newspack\Group_Subscription::get_group_subscriptions_for_user( $user_id, $statuses );
// Array of all group subscriptions with matching $statuses for which the user is a member (not owner)
= [
    518520 => WC_Subscription {#18050
      +refunds: [],
      +order_type: "shop_subscription",
    },
  ]

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[Copilot]

Pull request overview

This PR implements the business logic for managing group subscription members in Newspack. It adds functionality to associate user IDs with group subscriptions, retrieve members/managers for subscriptions, and check user access to group subscriptions.

Changes:

• Added member_ids field to subscription settings and UI for admins to manage group members via autocomplete
• Implemented utility methods for checking group subscription status, retrieving members/managers, and verifying user access
• Added AJAX handler for searching reader users to add as group members

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dkoo]

@miguelpeixe this should be ready for another look. There are some substantial changes compared to the first review:

• Group subscriptions are now stored as user meta with the _newspack_group_subscription key.
• Group subscriptions code is now split across three classes: Group_Subscription, Group_Subscription_Settings, and Group_Subscription_API as the single class file was starting to get pretty big already.
• The admin UI to add/remove members has been updated as we discussed: adding/removing of members now happens immediately via REST API instead of upon saving the subscription.
  • Maybe we can revisit this in a future PR as the current UI may be a little confusing (the "enabled" checkbox and "limit" setting are updated upon saving the subscription, while members are updated immediately).
  • To support this flow, group subscription is automatically enabled if not already enabled when adding or removing members, and get_members and get_managers methods now return found members/managers even if group subscription isn't enabled. This is so you can enable group subscriptions for a subscription and immediately start adding and removing members without saving first.

[miguelpeixe]

Looking great! Thank you for revising the approach. Besides copilot's feedback, I just have a few more comments.

[miguelpeixe]

With the 'high' priority it renders above the subscription details, which I don't think is ideal:

[dkoo]

Good call, I had dragged it to another location at some point and forgot about the default placement. c00655e adds the metabox on priority 26 so that it appears underneath the "line items" meta box by default:

[miguelpeixe]

Indeed, I'm getting duplicated users in my tests.

[miguelpeixe]

Non-blocking NIT, but do we need an API designed for bulk operations like that? A simpler CRUD approach is more convenient and easier to maintain.

[dkoo]

I initially wrote this as a bulk update method because of the original UI as a multi-select. I kept it because I thought it might be useful if we decide to implement a CLI command to bulk add/remove members for convenience in the future. Maybe this can be improved to abstract the add/remove actions into separate methods, though.

[miguelpeixe]

This is also non-blocking: I'm not sure user_can_access is the best name here. "Access" in the context of the subscription alone makes me think of access to something (like content), which is not a concern here.

Even though we include members and "managers", I find user_is_member() to be more straightforward.

[dkoo]

Updated in 6f43ff8

[miguelpeixe]

The query inside get_members() is not optimal for this.

We could go straight to the meta item with select 1 from {$usermeta} where user_id = '{$user_id}' and meta_key = '{$meta_key}' and meta_value = '{$subscription_id}' limit 1.

Or, to benefit from object caching, filter through get_user_meta( $user_id, self::GROUP_SUBSCRIPTION_USER_META_KEY, false ).

[dkoo]

Ah, I never updated this method after we switched the data to user meta. f194e06 updates it so that we use get_group_subscriptions_for_user() (which itself calls get_user_meta() instead of running a user meta query.

[dkoo]

@thomasguillot as discussed on the content gating call, tagging you for a design review of the core UI proposed in this PR. If you think we should go in a very different direction for the UI in either the product or subscription admin pages (or both), then let's consider tackling that in a separate PR after this one lands.

[dkoo]

@miguelpeixe pushed some other fixes to address your feedback:

• 8cdcecc updates the docblock for get_subscription_product_id() to reflect that the arg can be either a subscription ID or object, and the return value can be int|false
• c00655e tweaks the priority of the metabox so that it appears after the line items box, by default
• b731b96 fixes the user search to use the search term with wildcards (*search* instead of search), and to avoid duplicates between the two queries (I wasn't seeing duplicates that I expected to see because the lack of wildcards meant I wasn't actually getting all of the matches in my site)
• 6f43ff8 renames user_can_access to user_is_member
• f194e06 updates the user_is_member() method to use get_group_subscriptions_for_user(), which should be more performant than running a user meta query by subscription ID.

[miguelpeixe]

Thank you for the revisions! Changes look great and test well.

Just a minor question/suggestion that I missed in my previous review.

[miguelpeixe]

Apologies for not noticing this sooner, but should this be a concern here? It adds complexity and additional queries to the method. Regardless of the subscription status, the user is still a member of it.

IMO, status validation should happen by the feature that uses it.

[dkoo]

Agreed, 4e265e7 simplifies that method so that it takes just one arg ($user_id) and always returns an array of WC_Subscription objects.

[miguelpeixe]

I liked ids_only, though. It avoid running wcs_get_subscription() for every item if the caller knows it wants to match a particular subscription (like user_is_member())

[dkoo]

Gotcha, de139cd restores that arg

[dkoo]

Thanks for the review and feedback, @miguelpeixe!

[github-actions]

Hey @dkoo, good job getting this PR merged! 🎉

Now, the needs-changelog label has been added to it.

Please check if this PR needs to be included in the "Upcoming Changes" and "Release Notes" doc. If it doesn't, simply remove the label.

If it does, please add an entry to our shared document, with screenshots and testing instructions if applicable, then remove the label.

Thank you! ❤️

[dkoo]

Whoops, sorry, @thomasguillot! I forgot I tagged you on this before merging. If you do have any feedback on the core admin UI stuff here, let's handle changes in a new PR. You can comment on this PR with any feedback you have. Thanks!