MNTOR-2182/deprecate feature flags

[rhelmer]

References:

Jira: MNTOR-2182

Description

• Pare down the feature flag admin UI
  • only expose add, delete, and enable
• Mark feature flags as deprecated, features should move to Use an experiment, rather than a flag, for the last scan date #4443 when it lands.

How to test

The feature flag UI now allows removing flags, which doesn't actually delete them but sets the deleted_at column in the database. Flags can be re-added.

Checklist (Definition of Done)

• Commits in this PR are minimal and have descriptive commit messages.
• Jira ticket has been updated (if needed) to match changes made during the development process.
• Jira ticket has been updated (if needed) with suggestions for QA when this PR is deployed to stage.

[flodolo]

On an internationalization note: first+middle+last is a concept bound to create issues somewhere, just asking for a name might be easier. Middle name is a foreign concept even in most Western countries.
https://softwareforgood.com/why-you-should-stop-asking-for-first-and-last-names-on-forms/

[rhelmer]

On an internationalization note: first+middle+last is a concept bound to create issues somewhere, just asking for a name might be easier. Middle name is a foreign concept even in most Western countries. https://softwareforgood.com/why-you-should-stop-asking-for-first-and-last-names-on-forms/

Thanks, I actually only had this for demo purposes and didn't mean to have it in this PR (@flozia is working on the actual implementation of this). I would prefer we didn't have separate name fields too, it's something that the provider requires in this case unfortunately.

[Vinnl]

@rhelmer How would you feel about us removing the feature flag UI and infra altogether? Instead, to test locally, you could modify the default values in nimbus.yaml, and on stage and production, change the rollout in Experimenter to 0% or 100% as desired. That would ensure we have a single source of truth, and save us a bunch of code. I've worked that out in #4443, using many of the changes from this PR.

[rhelmer]

@rhelmer How would you feel about us removing the feature flag UI and infra altogether? Instead, to test locally, you could modify the default values in nimbus.yaml, and on stage and production, change the rollout in Experimenter to 0% or 100% as desired. That would ensure we have a single source of truth, and save us a bunch of code. I've worked that out in #4443, using many of the changes from this PR.

OK sorry I missed this comment, yes I think we could do this. Ideally I'd like to have a local environment in the nimbus config, I worry about changing defaults in local files while testing, these are too easy to accidentally commit.

[rhelmer]

@rhelmer How would you feel about us removing the feature flag UI and infra altogether? Instead, to test locally, you could modify the default values in nimbus.yaml, and on stage and production, change the rollout in Experimenter to 0% or 100% as desired. That would ensure we have a single source of truth, and save us a bunch of code. I've worked that out in #4443, using many of the changes from this PR.

OK sorry I missed this comment, yes I think we could do this. Ideally I'd like to have a local environment in the nimbus config, I worry about changing defaults in local files while testing, these are too easy to accidentally commit.

@Vinnl I went ahead and changed the remit of this PR, it's now about deprecating feature flags. I think we need to do it in stages though since we have features shipped right now and also in review that are behind flags, let's land the cleanup and simplification of the UI (plus the delete button), and I can mark the code as deprecated. We already have a tech debt ticket to remove feature flags, so we can finalize it and remove all flags from the DB.

After that's all done, we can remove the feature flag code. We might want to leave the feature_flags table as it has a record of what was shipped and when.

[rhelmer]

Changing the purpose of this PR slightly, going to wait for #4443 to land and will rebase on top of that. This will simplify the feature flag UI and mark feature flags as deprecated, and some small related cleanup.

[Vinnl]

@rhelmer I landed #4443, let me know when you've rebased :)

[rhelmer]

@rhelmer I landed #4443, let me know when you've rebased :)

It's rebased!

[Vinnl]

Really nice to have the deletion now too, makes it a bit cleaner. I'd maybe check with QA that they're not using the allowlist still though, just in case we're blocking their work for existing feature-flagged features.

[rhelmer]

Really nice to have the deletion now too, makes it a bit cleaner. I'd maybe check with QA that they're not using the allowlist still though, just in case we're blocking their work for existing feature-flagged features.

I don't think we need the allow list for any features that are in-flight or planned, we needed it for Plus but in general I think we can just enable everything on stage. I'll add it back if I'm wrong, I just removed from UI but left the API and DB parts alone :)