Currently env vars are edited individually with exposed IDs. Per sneak's feedback on PR #158:
We don't need to change env vars individually. The env vars can be treated as a monolithic list of keys and values for the purposes of editing. Individual env var IDs never need to be exposed. When updating we can simply remove all existing env vars and insert the full post-edit list provided by the client.
This means:
Edit page shows all env vars as a simple key=value list (textarea or multi-row form)
On save, delete all existing env vars for the app and insert the full new set
No individual env var IDs exposed in the UI
Simpler handler logic (no per-var CRUD endpoints needed)
Currently env vars are edited individually with exposed IDs. Per sneak's feedback on [PR #158](https://git.eeqj.de/sneak/upaas/pulls/158):
> We don't need to change env vars individually. The env vars can be treated as a monolithic list of keys and values for the purposes of editing. Individual env var IDs never need to be exposed. When updating we can simply remove all existing env vars and insert the full post-edit list provided by the client.
This means:
- Edit page shows all env vars as a simple key=value list (textarea or multi-row form)
- On save, delete all existing env vars for the app and insert the full new set
- No individual env var IDs exposed in the UI
- Simpler handler logic (no per-var CRUD endpoints needed)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Currently env vars are edited individually with exposed IDs. Per sneak's feedback on PR #158:
This means:
no, the edit page UI should stay the same. it’s just the client-server interaction that changes.