Feedback

What should we build next?

Browse boards, vote on ideas, share your own.

CRITICAL: cpanel_credentials RLS policy is non-functional (using(true))

Imported from GitHub issue [El-SaMa/oma#95](https://github.com/El-SaMa/oma/issues/95) by @El-SaMa. --- **Severity: Critical — active in production** \`packages/db/migrations/0051_cpanel.sql\` lines 24-26, 52-54: \`cpanel_credentials\` and \`cpanel_provisioned_service\` RLS policies are named \`"staff only"\` but their predicate is literally: \`\`\`sql using (true) with check (true) \`\`\` This grants **any authenticated (or anon, depending on grants) role** full read/write access to cPanel API tokens and provisioned-account records — no access control at all. **Fix:** replace with \`using (is_any_staff_member()) with check (is_any_staff_member())\`, consistent with every other credential table (enhance_credentials, hetzner_settings, etc.). Must ship together with the \`is_any_staff_member()\` scoping fix (#1) so it doesn't just open the door to "any org owner" instead of "anyone."

BugOpenGeneral·28 days ago·0

CRITICAL: is_any_staff_member() grants platform-wide admin to any org owner

Imported from GitHub issue [El-SaMa/oma#94](https://github.com/El-SaMa/oma/issues/94) by @El-SaMa. --- **Severity: Critical — active in production** \`is_any_staff_member()\` (used by ~18 RLS policies: enhance_credentials, hetzner_settings root passwords, billing_settings, support_mail_*, enhance_db_node_credentials, etc.) checks \`memberships.role IN ('owner','admin','staff')\` with **no organization filter**. Any customer who owns their own hosting org (the normal state via \`organizations.owner_user_id\`) passes this check and gets platform-wide staff access to every other customer's data. App-layer equivalent (\`resolveRoleForUser\` in \`apps/web/lib/roles.ts\`) had the identical bug. **Fix drafted, not yet deployed:** - \`packages/db/migrations/0053_fix_staff_role_scope.sql\` — redefines \`is_any_staff_member()\` to check membership in one specific staff org UUID (Lanetti, \`edb40deb-e0ac-49f6-ab39-1efee07831a7\`) - \`apps/web/lib/roles.ts\` — \`resolveRoleForUser\` now scoped to \`STAFF_ORGANIZATION_ID\` **Prerequisite:** the platform operator (\`[email protected]\`) must be added as \`owner\` of the Lanetti org first, or this fix locks out the operator's own admin access (neither \`OMA_STAFF_EMAILS\` nor \`OMA_STAFF_ORGANIZATION_ID\` is set in production, so admin access currently depends entirely on the same unscoped membership lookup). **Exposure:** currently 13 real customer accounts have unintended \`owner\`-role-driven staff access.

BugShippedGeneral·28 days ago·0

siteManage i18n namespace missing from 19 of 22 locales

Imported from GitHub issue [El-SaMa/oma#104](https://github.com/El-SaMa/oma/issues/104) by @El-SaMa. --- **Customer-facing bug.** The \`siteManage\` translation namespace (used by \`database-users-panel.tsx\`, \`databases-list-panel.tsx\`, and the rest of the service-management panels — including the new Kanta IP-access-control panel) exists in only \`en.json\`, \`fi.json\`, and \`sv.json\`. The other 19 locale files (ar-EG, da, de, es, fr, hi, id, it, ja, nb, nl, pl, pt, ru, tr, uk, zh) are missing it entirely. Customers on any of those 19 locales see broken strings or English fallback on every service-management page right now. **Fix:** backfill the \`siteManage\` namespace into all 22 locale files (English copy as placeholder is acceptable short-term, but it needs to exist so the key doesn't throw/fallback silently). Expand \`i18n-validate.mjs\` to enforce strict parity for portal namespaces (currently only enforced for en/fi/sv), not just landing/marketing keys, and wire it into CI.

BugShippedGeneral·28 days ago·0

CRITICAL: deploy runs migrations with no dry-run, no pre-flight check, no halt-on-failure

Imported from GitHub issue [El-SaMa/oma#108](https://github.com/El-SaMa/oma/issues/108) by @El-SaMa. --- **Severity: Critical for a live solo-operator system.** \`migrate.mjs\` supports \`--dry-run\`, \`--baseline\`, and \`--to=\` flags — none are ever invoked. \`scripts/docker-stack-up.sh\` line 37-38 runs migrations blind, and line 41 starts containers regardless of whether the migration step succeeded. A broken migration leaves the stack running against a half-migrated schema with no automatic halt. CI also never dry-runs migrations against a throwaway DB, so a broken migration is only ever discovered live, during deploy, in production. **Fix:** 1. Add a CI step: \`docker compose run --rm migrate node migrate.mjs --dry-run\` against a throwaway Postgres, on every PR. 2. Make \`docker-stack-up.sh\` halt (non-zero exit, don't proceed to \`docker compose up -d\`) if the migrate step fails.

BugShippedGeneral·28 days ago·0