Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's not clear why can't create a flag without variants #874

Closed
mechamobau opened this issue Jun 7, 2022 · 2 comments · Fixed by #876
Closed

It's not clear why can't create a flag without variants #874

mechamobau opened this issue Jun 7, 2022 · 2 comments · Fixed by #876
Assignees
Labels

Comments

@mechamobau
Copy link

mechamobau commented Jun 7, 2022

Describe the bug

When I create a flag without variants, go to targeting and try to create a flag the submit button "Add Rule" is disabled. This was possible before updating to the current version.
It's not clear why I can't create a new flag, maybe it's a bug or this should have a feedback message about why it's not possible to perform the action.

Version Info

1.8.2

To Reproduce

  • Create a new flag
  • Go to Targeting
  • Click on "New Rule"

Expected behavior

Create a new flag without variants, returning "" on value field on each request.

Screenshots

image

@markphelps
Copy link
Collaborator

👋🏻 Just want to make sure I understand, you can create the flag but it won't allow you to create the rule because there are no variants? It should still allow you to make the flag, but just not add any rules which are used for evaluation. You should still be able to use GetFlag to check if the flag is enabled or not though.

This changed in https://github.com/markphelps/flipt/releases/tag/v1.7.0 (#759) because rules only make sense when there is at least one variant to return (at least that was my thought process).

Maybe adding a tooltip explaining this reasoning on the blurred out Add Rule button would improve the usability?

If there is a use case for allowing rules with no variants I can also undo the change in #759. Would just have to make sure this doesn't re-introduce any UX bug or anything that #759 may have fixed (I should have given better justification for that PR, sorry about that).

@markphelps
Copy link
Collaborator

Actually I think you are right that this should go back to pre 1.7.0 behavior. I just tried it out on v1.6.3 (last one before 1.7) and it was intuitive

Screen Shot 2022-06-08 at 6 18 21 PM

I'll revert the change in #759 and create a new release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants