Implement API Filter so users can only list Public Contact Groups

[JoseSzycho]

Currently, when users retrieve contact groups, they can list all of them, which is incorrect.

Private groups should only be retrieved if they have a ContactGroupMembership for that specific group.

[JoseSzycho]

@scotwells Could you provide some guidance on how we should handle private ContactGroups?

I need users to be able to list groups so they can opt-in or opt-out. I tried implementing a visibility filter that relies on existing membership: if a group is private and the user isn't already a member, the filter hides it entirely.

I feel this filtering workaround is brittle, as I also need to prevent membership creations to that private groups. It also inadvertently affects Staff users: since the filter is applied globally based on user context, it blocks admins from correctly managing private groups they don't personally belong to.

I explored using our standard authorization model to solve this, but it became overly complex to granularly grant 'manage' permissions for memberships of specifically private groups.

Do you think the best approach would be to create custom API endpoints for these actions, rather than relying on standard REST filtering? I would appreciate your advice, as I'm finding it difficult to solve this cleanly using our current API patterns.

[scotwells]

The filter option would be the best path forward with our current system so that users can only query for contact groups through the user context. Staff users would query for contact groups through the global context and would bypass the filter that's in place.

Long term we'll have a search endpoint that lets users query for resources that only have access to which should eliminate the need to do this type of filter.

[JoseSzycho]

Great, I will continue with the filter option.

Thanks for the feedback