API: Enhance permissions to allow filtering by environments

[rajdip-b]

Description

Right now, the roles that are created can have one or many projects associated with it. Associating projects mean that members who will have this role attached to them, will be able to perform the authorities in WorkspaceRole entity [refer to prisma schema].

We would like to have another layer of security in here. We would also like to introduce environment specific access, so that members can have access to only a specific set of environments in the project set by the admin.

Use case:

Consider that there's a project that has 3 environments - dev, stage and prod. It will be ideal to allow the developers access the dev and stage environments (and the secrets and variables in it) while the prod environment is only accessible by the DevOps team or such. This is where this feature will be helpful

Solution

• Update the ProjectWorkspaceRoleAssociation entity to include environments - specifying the environments accessible by the member.
• Create a reverse relation from Environment on to ProjectWorkspaceRoleAssociation.
• Add a util function named getCollectiveEnvironmentAuthorities. You can take the reference from any get-collective-project-authorities.ts. The purpose of this function would be this: given the userId, project, and environment, it would need to fetch all the authorities that the member has over this environment.
• Update AuthorityCheckerService#checkAuthorityOverEnvironment to incorporate the getCollectiveEnvironmentAuthorities function and filter the roles.
• Update the projectIds to be a of type Map<String, Array<String>>. The association will be something like this: For every projectId, list of environmentIds that will be available to the role.
• Update the WorkspaceRoleService functions acordingly
• Update the required tests in workspace-role module.

[rayaanoidPrime]

/attempt

[github-actions]

Assigned the issue to you!

[rajdip-b]

Hey @rayaanoidPrime! Could you hold up to this for a day or two? I'm making a major refactor to the way secrets, variables and environments are organized. I would notify you once its done.

[rayaanoidPrime]

Oh sure no worries

[rajdip-b]

Hey bro! @rayaanoidPrime

v2.0.0 just got released! You can start working now. Do hit me up if you want help.

[rajdip-b]

Howdy @rayaanoidPrime, any updates yet?

[rayaanoidPrime]

Hey @rajdip-b sorry for being unresponsive just been kinda busy last few months. I remember being done with it and I think only the tests are left to be written. Let me see if I can do a pr this afternoon.

[rajdip-b]

No rush bro! Just let us know when you can put up the PR.

[rayaanoidPrime]

Hi! In light of the evolutions and additions that the code has undergone in the time after this issue was posted I have thought of a few changes to the initial solution format. (the core logic remains the same ). Let me know your thoughts

1. Update CreateWorkspaceRole DTO:

class CreateWorkspaceRole {
  // ... other properties ...
  @IsOptional()
  @ValidateNested({ each: true })
  @Type(() => ProjectEnvironments)
  readonly projectEnvironments?: ProjectEnvironments[]
}
class ProjectEnvironments {
  @IsString()
  projectSlug: string
  @IsArray()
  @IsString({ each: true })
  environmentSlugs: string[]
}

3. Modify WorkspaceRoleService :: createWorkspaceRole and updateWorkspaceRole methods to handle new project-environment associations.
4. Revise workspace-role.e2e.spec.ts:

• Update existing tests and add new ones to cover the new functionality.
• Create actual environments (Dev and Prod) for each project in the test setup.
• Use these created environments in the tests instead of undefined environment names.

5. Update checkAuthorityOverEnvironment to incorporate the getCollectiveEnvironmentAuthorities function and filter the roles.
6. Add new helper function in WorkspaceService:
   • Create a new private method getEnvironmentSlugToIdMap to fetch environment IDs:

   private async getEnvironmentSlugToIdMap(environmentSlugs: string[]) {
     const environments = await this.prisma.environment.findMany({
       where: {
         slug: {
           in: environmentSlugs
         }
       }
     })
     return new Map(environments.map((env) => [env.slug, env.id]))
   }

   This function takes an array of environment slugs, queries the database to find matching environments, and returns a Map with environment slugs as keys and their corresponding IDs as values.

[rajdip-b]

Yes! I believe that's what needs to be done. Thanks for the detailed writeup.

[rajdip-b]

@rayaanoidPrime hey bro long time no see. I'm unassigning this for now. Feel free to pick this up later on.