You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to have more granularity over the scope the feature was active for. Activating the feature for the entire application, while useful, doesn't really let us leverage the full power of feature flags / switches. In particular, things like a ramped-up rollout require more control than just on or off.
Some of the scopes that we would want would be:
Session: This lets us try things out or demo things, but only have it enabled for our current browsing session. We would also use this to turn things on in one browser but not another to show the difference between the feature being on or being off.
User: Being able to activate a feature only for certain users would give us fine-grained control for things like beta-testing or for doing A/B testing. Obviously, not of any use if there isn't the concept of a User in an app, but doesn't seem to be the norm.
User Group: Same as for single users, but less overhead to manage. I would expect this would align with a role-based permission system in most cases.
The text was updated successfully, but these errors were encountered:
I completely agree with this. However, applying functionality to certain users could be tricky without tying ourself to a perticular authentication mechanism.
I'm not sure when we'd have the time to add this functionality, but as always I'm happy to receive pull requests (with appropriate tests, of course) if you feel inclined!
I guess I was thinking that something along the lines of what the Plugin Platform Core plugin provides would be sufficient to be able to determine the user and their role(s). This would allow you to be coupled only to an abstraction and it would be up to whatever security plugin the user wished to use to take care of the actual implementation.
And keeping the switch state only over the current session should not require any dependencies, since a session has to exist for the Grails Flash scope to work.
In part, I posted the issue to serve as a reminder to myself (and anyone else) that, when I find time, this would be a good thing to contribute. If someone else, including the maintainers, get to it first, fantastic, but I will certainly contribute back anything we put together to give us the functionality we need. Taking the first steps (as you have done with the plugin) is the hardest part, so thank you :)
We have implemented some thing as features plugin internally at our organization, and it is coupled with shiro.
Our requirement is to be able to turn feature on/off for different users/roles/groups so that we can have different features for paying vs non paying customers. Though our stuff is already working. However having features plugin offer some thing similar would be great
It would be great to have more granularity over the scope the feature was active for. Activating the feature for the entire application, while useful, doesn't really let us leverage the full power of feature flags / switches. In particular, things like a ramped-up rollout require more control than just on or off.
Some of the scopes that we would want would be:
The text was updated successfully, but these errors were encountered: