BUG: Critical server-side authorization missing for ticket/task/meeting mutations

[g-k-s-03]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Issue Overview
Several sensitive operations (such as assigning tickets, updating status/priority, deleting meetings or tasks) are executed directly from the client using the Supabase SDK. These operations rely on UI checks or assumptions that Row Level Security (RLS) will always enforce correct permissions.

If RLS policies are missing, relaxed, or modified in the future, any authenticated user could perform privileged actions across teams or roles.

This creates a broken access control risk where security depends on external configuration rather than guaranteed server-side enforcement.

Steps to Reproduce

1. Log in as a normal team member (non-admin).
2. Intercept or modify a client request (or call the SDK directly).
3. Call any of the following methods with arbitrary IDs:

• assignTicket
• updateTicketStatus
• updateTicketPriority
• updateMeeting
• deleteMeeting

4. Observe that the client allows the request to be sent without validating role or ownership.
   (If RLS is misconfigured, the operation will succeed.)

Expected Behavior
All privileged mutations should be enforced strictly on the server:

• Only team members can modify resources of their team.
• Only admins (or creators) can assign, delete, or update approval/status fields.
• Authorization should be guaranteed via RLS policies or SECURITY DEFINER RPC functions, not UI logic.

Actual Behavior
The client directly executes update/delete operations and assumes the database will block unauthorized actions. There is no hard guarantee in the client layer that the caller has sufficient permissions.

Security currently depends entirely on RLS correctness.

Suggested Improvements

Move all privileged operations to one of:

1. Strict Row Level Security (RLS) policies for each table (tickets, tasks, meetings, comments).
2. Or dedicated RPC functions that validate:

• team membership
• role (admin/member)
• ownership (creator)

This ensures that even if client logic is bypassed, unauthorized actions are impossible.

Record

• I agree to follow this project's Code of Conduct
• I want to work on this issue

[g-k-s-03]

@SharkyBytes I’d like to work on a proper solution.

My plan is to:

• Audit current RLS policies for tickets, tasks, and meetings.
• Identify which privileged mutations should be enforced via RLS vs RPC.
• Propose minimal changes (policies or SECURITY DEFINER functions) to guarantee server-side authorisation.

I’ll start with tickets first and open a draft PR once the direction is confirmed.