Feature Flags

FR - Add verbose logging in the read pod log to indicate status changes and the initiation of the polling mechanism for recovery. Reason.- When the write proxy experiences a temporary disconnection and reconnection, the Server-Sent Events (SSE) may break, leading to a 503 error and a failure in the polling recovery mechanism.

I want to have a UID for a feature flag in case my developer creates a flag with the same name as a historical feature flag created in the past. This will allow the flag to be created but keep metrics and other analytics separate.

Improvement around making the editConfig more granular so an enterprise can further split different permissions (i.e. Tag Management)

The current RelayProxy V2 key edit functionality allows users to accidentally assign production project keys to non-production environments and vice-versa. This can lead to security vulnerabilities and unexpected behavior. Can you implement environment demarcation during the edit phase of RelayProxy V2 keys. This would ensure that users can only assign keys to environments that match their intended purpose (production keys for production environments and non-production keys for non-production environments).

The user would like the ability to create and control tags at the account level that would be available for multiple projects as needed.

Currently, in the Target Groups where we set target rules, all the line entries are treated as "OR." I need an "AND" operator to combine multiple rules. For example: I have created a flag - FLAGA. My targets will have two attributes - STATE and ZIPCODE. I want to target customers who reside in STATE = CA 'AND' ZIPCODE = 94403. The current target rules only allow 'OR.'

Today flag owners can't be edited. This is important in today's product behavior because some customers rely on this to be immutable. However, some customers are requesting the ability to edit for a variety of reasons including spelling mistakes, change in employees, or ability to add service owners instead. We are looking for more customer feedback and interest on this request! Please vote and add your use case.

Based on the RBAC model defined, a User is given create access. Hence, when a feature flag is created, it gets created in all environments. As the create+edit permission is clubbed, the User is able to edit (add targets and variations) in the prod environment. Our requirement is for a User to be able to create the feature flag in prod, but to be not able to do any form of edit to it. This will require harness to treat create and edit as two separate functions and to be assignable when defining RBAC rules.

Ability to create and delete a flag for a particular environment. Currently when you create a flag it exists across all environments and when you delete a flag it deletes across all environments.

After we enabled PIE_MULTISELECT_AND_COMMA_IN_ALLOWED_VALUES , all <+input>.allowedValues(...) become multiple selection Please add support of multiple selection and single selection inputs int the same pipeline. Requirement: when one pipeline contains input variables <+input>.allowedValues(aa,bb,cc) <+input>.allowedValues(11,22,33) want to implement #1 multiple selection, #2 single selection