Inform users why their flag status doesn't change
under review
D
Denim Gerbil
A slight bug or misleading inconsistency is in Harness FME. When you take a flag that is initialized in 0 environments and try to update its status (Removed from Code for instance), the action "succeeds", but the flag status stays the same. It's assumingly because the flag shouldn't really have a status when completely uninitialized, but it doesn't help that the end user doesn't get that info--they just see a broken action.
Update 4-2-26 3:56 pm
looks like it's less to do with the environments being uninitialized and more like where the initiating action comes from--coming from the flag details page gives a less-privileged user no warning that their flag change didn't go through, but coming from the rollout board always works.
Log In
d
david.karow
Thanks for the post.
I tried changing flag status as a view-only user, and I want to check in with what you mean by "coming from the rollout board always works" -- did you mean by that that you get an easily seen error message, or that the user actually was able to change the status?
- In the feature flag "Edit details" flow, my attempted save displayed a red banner at the top of the dialog that said, "Something went wrong with Something went wrong, please try again.. Please try again." -- looks like we concatenated two error messages there, which we should clean up, but there was feedback, and the dialog did not self-dismiss, so there was time to see it.
- In the rollout board, attempting to drag and drop the flag from one status to another visually looks like it is going to work, but when you drop the flag into the new column, two error toasts show up bottom right and the flag pops back to the status column it was dragged from.
Let me know if your "less-privileged user" had more powers than view-only and if I've missed something here, and I'll be happy to re-test on my end.
Photo Viewer
View photos in a modal
d
david.karow
marked this post as
under review
D
Denim Gerbil
david.karow
Hi David, thanks for taking a look. When I said "coming from the rollout board always works", what I meant was that when on the Rollout Board, a less-privileged user was able to:
a) attempt to change a flag status
b) get a pop-up confirming the success of their change
c) verify that the flag status change actually took effect
that seem less-privileged user when on the flag details page was able to:
a) attempt to change a flag status
b) get a pop-up confirming the success of their change
BUT
c) they were able to verify that the flag status change DID NOT actually take effect (a ghost/phantom success)
d
david.karow
Denim Gerbil: Thanks Connor! Does the user who encountered this have the permission to edit flags in some environments, but not in others? My guess is that there is an implied "current" or "last accessed" environment and that the permissions the user has in that environment may be what's causing this inconsistent behavior. Can you have a look and see what happens if that same user views a flag definition in an env that they DO have edit perms in, and then immediately create a new flag and retry the status change? If that works, then I'll have a much better target to go after for a fix.
For sure we need to fix the feedback if the change fails regardless... silent failures are the least friendly kind :-)
D
Denim Gerbil
david.karow Hi David! At first we weren't sure if this would be a feature request or more of a bug, so we also submitted a support request. On there we uploaded a .HAR recording of the use. Would that be helpful? Or should we maybe just let that ticket play out and close this canny item?