Kos
commented
5 years ago Documentation of filter syntax
In the implementation idea described above, each Subject can define its own filter string syntax and meaning. The meaning has to be clear to the user who selects the Subject from the dropdown in Rollout Django Admin page.
For example, the built-in IPAddress filter could naturally allow filtering by IP ranges, but there's no single obvious syntax for this: regex? wildcard? CIDR notation? Whatever ends up to be the case, the user has to learn somehow.
Same for any other rollout: how would "Users with name" work? is the name sensitive or not? Does it match the first name, last name or both? What about a subject named "Users matching pattern"? Generally, the subject name will be a good hint what the filter string means, but it's not good enough UX wise.
Ideally, we would require each filterable subject to provide this documentation as a string, and show this to the user in Django Admin page while creating the Subject. This would probably needs a custom Admin widget.
Rationale
Currently each rollout can be configured to target either a subject, or a percentage-based slice of a subject.
There should be a way to further narrow down a subject by something meaningful. Assuming you have a subject "Users", you could derive filtered subjects along the lines of:
A possible implementation is to have a distinction between:
where a filterable Subject can be parametrised with a string and the meaning of the string is specific to the particular Subject. This means that "Users with email..." and "Users with id..." would be separate subject classes that only differ by how they interpret the filter string. It would be difficult (UX wise) to provide a good way to do a single rollout for "Users with email ... or id ..."), unless you write a very specific Subject for this case & figure out a language that allows to encode the parameters in a single string.
Combining with percentage based rollouts
Since all Subjects already have a way to slice by percentage (built-in), we need to define how this would interact with filter strings.
A trivial implementation of implementing "roll out to 50% users with email ending with gmail.com" would be to test if the user's flag score is <= 50% and if the email ends with gmail.com. This should be in line with what the user expects as long as the flag score doesn't obviously correlate with the e-mail.