[AI] What to change: The top left dropdown-field showing all projects associated w...

[burkongla]

Automated PR

Task: What to change: The top left dropdown-field showing all projects associated w...
Description: What to change: The top left dropdown-field showing all projects associated with a certain account/profile.
• Make sure that only projects associated with the account, are shown in the dropdown menu. This means that if a person for example are admin for 3 projects and helper for 5, only the relevant projects (the projects the profile has access to or are validated for are shown). For an admin this means that the project must be added by the person, or that the person is added as admin by other project owner of the project in question. For helper, this means that the helper must be validated as helper for the project in questions. This can only happen in two ways: The person adds himself as helper, from the Helper page for Admin. Or the person request to be validated as helper for a specific projects, and later is approved as helper for the project the person request to be a helper for.
Do not change: Anything else than what is listed.
Acceptance criteria: When all points listed under “Description and specific values” are implemented the task is done.
Source: slack
Requested by: U04E9DZ5ELF
Classification: flow

Changes

The project dropdown in the top bar shows every project the user has any projects_members row for, regardless of role. Update the useUserProjects hook so the dropdown only lists projects where the user is a validated admin (projects_members.role = 'admin') or a validated helper (a row in projects_helpers, which only exists after self-adding via the Helper page or being approved after a request).

Security Review

Status: warn
The diff itself is safe: no secrets, no injection (PostgREST parameterizes .eq/.in), projects_helpers has RLS enabled with a correctly scoped SELECT policy (is_project_member OR user_id = auth.uid()), and the table has no soft-delete column so no stale-helper access. Advisory only: the projects table's USING (true) SELECT policies make the client-side project filtering cosmetic — all project rows are readable by anyone with the anon key, which this hook's select("*") leans on.

Warnings:

• src/hooks/useProject.ts: Pre-existing (not introduced by this diff, but this change widens who reaches this code path): the final .from("projects").select("*").in("project_id", projectIds) query relies on the projects table RLS for enforcement, and the backend dump shows projects_select_all ... FOR SELECT TO authenticated USING (true) plus "Enable read access for all users" ... FOR SELECT USING (true) (no role restriction, so anon too). The client-side .in() filter is cosmetic — any user can read any project row (all columns) by crafting their own query with the anon key.
• src/hooks/useProject.ts: The comment states a projects_helpers row exists once the helper is 'self-added or approved', but the RLS insert policy is projects_helpers_insert_admins (admin-only). Self-addition must therefore go through a service-role Edge Function; the comment overstates the client-side path. Misleading authorization comments tend to cause future privilege mistakes (e.g. someone 'fixing' the insert policy to allow self-inserts).

---

🤖 Generated by githelp-support agent team

[netlify]

✅ Deploy Preview for githelp-support ready!

Name	Link
🔨 Latest commit	b9d211f
🔍 Latest deploy log	https://app.netlify.com/projects/githelp-support/deploys/6a8dda4cc30fe10008927377
😎 Deploy Preview	https://deploy-preview-211--githelp-support.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.