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

make flags more configurable and protect the ones the code cares about #1521

Open
cellio opened this issue Jan 21, 2025 · 0 comments
Open

make flags more configurable and protect the ones the code cares about #1521

cellio opened this issue Jan 21, 2025 · 0 comments
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

Comments

@cellio
Copy link
Member

cellio commented Jan 21, 2025

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.

@cellio cellio added area: backend Changes to server-side code type: change request New feature or request priority: medium complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant