make flags more configurable and protect the ones the code cares about #1521
Labels
area: backend
Changes to server-side code
complexity: unassessed
Needs further developer investigation before complexity/feasibility can be determined.
priority: medium
type: change request
New feature or request
Flags are configured using a YAML file, with no UI for managing them. Adding a new flag type requires rerunning that file and can lead to duplicate entries. We have code that depends on specific flag names, and if those names ever got edited in the YAML file, either for an existing instance or before setting up a new one, that code wouldn't work. But the presence of the YAML file hints to maintainers that they can edit these. They might think editing (for example, for translation) is safe.
Can we instead use the approach that we take for close reasons? There's an initial set, but there's also a UI for managing them. We could prefill the ones we want to "protect" (ones the code cares about) and either make them non-editable or give them permanent IDs that code could refer to. Our code would be more resilient if it could refer to $spam_flag_id, defined in code, instead of "it's spam" defined in a YAML file.
The text was updated successfully, but these errors were encountered: