PostHog / PostHog/posthog-ruby

Filter feature flags by group type in SDK and `/feature_flags` endpoint

Open
#110 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement feature/flags
Dominant language
Ruby
Stars
36
Forks
34
Avg merge
1d 13h
Merged PRs (30d)
18

Description

Context

We are using PostHog feature flags with group analytics to manage per-project feature toggles in our application. We have a project group type and want to allow users to opt-in/out of features for their specific project.

Current Behavior

When calling get_all_flags with a groups parameter, PostHog returns all feature flags regardless of their targeting type - person-based flags, group-based flags of all group types, etc.

client.get_all_flags(
  distinct_id,
  groups: { project: "project-uuid-here" }
)
# Returns ALL flags: person-based, project-group, space-group, etc.

The groups parameter serves as an evaluation context, not as a filter. There seems to be no way to retrieve only the flags that target a specific group type.

Expected Behavior

It would be useful to have the ability to filter the response to only include flags that match a specific group type. For example:

client.get_all_flags(
  distinct_id,
  groups: { project: "project-uuid" },
  filter_by_group: :project  # only return flags associated with a "project-uuid"
)

Use Case

We have a dashboard where users manage features for their project. We need to display only the feature flags relevant to that project's group type, not person-level flags or flags targeting other group types. Currently, the only workaround I can think of:

  1. Using a naming convention/prefix to identify flags by group type
  2. Making a separate REST API call to /api/projects/{id}/feature_flags/ to fetch flag definitions with metadata, then cross-referencing

Both might work (I have not yet verified the 2nd flow), but feel like they shouldn't be necessary given that the flag definitions already contain this information.

Additional Context

This also relates to the early access feature management not supporting groups. For applications that need organization/project-level feature opt-in (rather than individual user opt-in), the current tooling requires significant workarounds.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Ruby SDK's get_all_flags implementation and the /feature_flags request or response handling; the issue names no specific files or tests. Review how flag definitions expose targeting group metadata and determine where filtering belongs. Done means callers can request flags for one group type while preserving existing behavior when no filter is provided, with coverage for person and other group flags.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
api
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.