[CRM][Backend] - Fix Authentication in Routes

[LOTaher]

Description

For context, Sarge is meant to be a self hosted platform. With that, we'll provide a way to cleanly distribute the code we write to anyone who'd be interested. With that, it is naive of us to assume that there will only ever be a single organization using a distributed version of the Sarge platform at a time. That is exactly what we're doing at the moment!

Currently, our API routes hardly take into account the organizationId of the user making a request. This means that if I call POST /api/task-templates/ and pass in a schema, I can pass in ANY organizationId. You can probably imagine why this is incredibly insecure.

The ask here is to go through every endpoint we have defined, and make sure that the service methods handle organization specific operations. This means you'd need to first retrieve the user session context in each of the controllers.

Secondly, our routes shouldn't only be accounting for the user's (caller's) organization, but also the user's role in the organization. In Sarge users can be:

• owner
• admin
• recruiter
• reviewer
• member

At the moment, all routes create delete and update operations should be of recruiter or above. Define utility functions in a file called /lib/utils/role.utils.ts to help you implement authentication where you need to.

To test these API's you'll need to sign in manually using your API platform of choice (Postman, cURL, etc). This also requires you to change the defined schemas within src/lib/schemas as our schemas should no longer have orgId passed into them directly, but instead alongside the rest of the body, but just within the controller.

These routes should now throw a ForbiddenException if the user doesn't have the proper role to perform this action. You can manually test the routes by changing your role manually in your db editor of choice by typing in the role in all lowercase as a string.

Requirements:

• Go through every route and make sure operations are at the organization level.
• Make sure users with specific roles can perform the correct operations, those who don't have the proper roles should have their routes throw a ForbiddenException. I suggest you make a util function that you can call at the top of each controller with an if condition.
  • You might want to research how to include the role of the user in our current getSession() function to make this easier for you.

Let @LOTaher know if you have any questions!

Acceptance Criteria

• Implementation matches requirements listed above
• Postman screenshots are provided
• Deploy branch to staging and do all the CRUD applications possible in a newly created organization

[bderbs30]

https://www.better-auth.com/docs/plugins/organization#access-control

I suggest reading up on this

lmk if you have other questions on membership and how better auth works @bderbs30

[kaiyangzheng]

start 2/2/2026

[kaiyangzheng]

Broad strokes implementation steps:

1. Define role.utils.ts
   • Create helpers to enforce role ordering, and have a function that asserts a user's role is recruiter and above for create, delete, and update operations
   • Define vars like a type OrgRole and a constant mapping role to rank ROLE_RANK
2. Update auth.utils.ts to get the role for a session in getSession
3. Remove orgId from request schemas
4. Update controllers to call getSession and return a ForbiddenException if the role isn't greater than recruiter
5. Update service methods to accept org-specific data (include where for org specific fields)

@LOTaher does this look right?