This is an interesting use case. One possibility would be to extend the comments to include the ID (or IDs) of the groups to which they are associated. This would make the comments' relationship to a particular group readily accessible to your code.

Then interpreting what a user was authorized to see would just be a matter of validating whether or not they were a member of the specified groups. To actively check that you might use the validation options available on the Member API. Alternatively, a more efficient approach might be to retrieve the list of groups of which a user is a member when they login and leverage that as a claim for what they can access.

(The Groups family of services includes a notion of an "association", which is intended to related content to Groups in the way that "members" relate people to groups. That said, I think extending comments instead may result in a less complicated/chatty implementation.)

Apologies if I've misinterpretted your question. I'm happy to clarify where ever I can.

Thanks for the reply.

Most my investigation has been around your second approach, but happy to look into your suggestion. The reason why I looked towards your second approach (assiciating content with groups, members with groups) is because the way I am thinking of building the forum using Comments is creating a content page for each sub forum, attaching Comments against that as initial forum topics/post and restricting responses against the initial comments so using the api can build up forum threads.

Unless architecturally there is a better way?

Agreed -- a content page for each sub forum is a good way to go. So, depending on how you prefer to approach it, a couple of options come to mind.

• You could tag the content page with the ID of the corresponding group. I think this would probably still give you a quick options comparison against the user's "member" data
• Alternatively, you could create "associations" for the content pages to relate them to groups. This would enable you to pull the identifiers for sub-pages by groups from the API.

My gut feeling is that the first option is likely the best fit. If feels like it carries less complexity than the second, assuming it meets your need.

Ok, just to make sure we're thinking the same thing.

When creating the sub forum (content page) we also set the corresponding group, I am guessing through a selection factory or something similar. We set users members data (using community api) to what groups they're in and then when authenticatitng we only display though content pages (sub forums) based on the groups the content pages are in vs. the groups the members are in.

Yes, exactly. Assuming that fits with your requirements of course. :)