Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove update environments from putOrganization. #2564

Merged
merged 11 commits into from
May 30, 2024

Conversation

mknowlton89
Copy link
Collaborator

@mknowlton89 mknowlton89 commented May 23, 2024

Features and Changes

This PR updates how we handle CRUD actions for an organization's environments. Previously most of this logic was nestled within the putOrganization method, and we're making an effort to reduce the overall power of that method and instead, handle the logic in specific controllers.

This PR removes the ability for an organization to update their environments via this method, and instead, moves it to the environments.controller.ts file.

This PR introduces/moves the following logic:

  • Adds specific delete route

  • Adds specific put/:id route

  • Adds specific updateOrder endpoint for move up/move down - prevents any backdoor to updating envs or any permission error but only accepting an array of ids

  • Updates the /post endpoint to accept the optional projects property (previously, we ignored this)

  • Updates the bulk update endpoint

  • Moves logic to fire any web hooks to specific controller methods

  • Updates EnvironmentModal to consume the PUT and POST requests (previously was using /organization)

  • Updates ‘environments.tsxto consume the new/environment/order` PUT request

  • Closes - [Feature] Update environment controller and remove ability to update environments from putOrganization #2494

Testing

  • Ensure that engineers, experimenters, and admins can still add, update, and remove environments without issue
  • Ensure that non-engineers, experimenters, and admins can't add, update, remove or change order of environments
  • Ensure that engineers, experimenters, and admins can move up/move down environments, even if its an environment you don't have permission to edit

@mknowlton89 mknowlton89 self-assigned this May 24, 2024
@@ -47,9 +101,107 @@ export const putEnvironments = async (
environments: updatedEnvironments,
},
});

await req.audit({
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into adding logic here to fire webhooks if an env's projects were updated, but the final argument to addEnvironmentToOrganizationEnvironments above is false, so we're not replacing any existing envs, we're ignoring them, so no existing env should see any changes.

@mknowlton89 mknowlton89 marked this pull request as ready for review May 28, 2024 19:05
Copy link

github-actions bot commented May 28, 2024

Your preview environment pr-2564-bttf has been deployed.

Preview environment endpoints are available at:

Copy link
Contributor

@romain-growthbook romain-growthbook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly questions and nitpicking stuff. The only strong suggestion is to use loadash to compare projects.

Comment on lines 61 to 70
const index = existingEnvs.findIndex((env) => env.id === environment);

if (index < 0) {
return res.status(400).json({
status: 400,
message: `Unable to find environment: ${environment}`,
});
}

updatedEnvs.push(existingEnvs[index]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for now using the plain find method?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the same code as putEnvironments. Maybe it could be factored out?

Copy link
Collaborator Author

@mknowlton89 mknowlton89 May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No good reason for using find vs findIndex. I'll update to find as it does make things a bit more concise.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I think for the putEnvironment it makes sense to keep the findIndex as with that, we want to find the index, so we can later update that specific index. I think find is better for the putEnvironmentOrder and deleteEnvironment, though.

const existingProjects = envsArr[existingEnvIndex].projects || [];
const newProjects = environment.projects || [];

if (JSON.stringify(existingProjects) !== JSON.stringify(newProjects)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comparison is bound to be runtime dependent on the order of keys in the object. lodash is used in the code already and has a comparison utility that seems better suited: https://lodash.com/docs/4.17.15#isEqual

Comment on lines +50 to +58
environment: z
.object({
id: z.string(),
description: z.string(),
toggleOnList: z.boolean().optional(),
defaultState: z.any().optional(),
projects: z.array(z.string()).optional(),
})
.strict(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be factored out to make it more visible for potential future re-use?

| "environment.create"
| "environment.update"
| "environments.update"
| "environment.delete"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you also need an entry in EntityType?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof - yes - great catch!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When doing the bulk updates - either via the putEnvironmentOrder or putEnvironments - there isn't a single env.id for the entity, so I've currently just got it set to the organization. Not sure if that's the right direction...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a PR changing those type definitions to take a constant object mapping entities to audit event names. This should fix these kind of gaps.

@@ -222,12 +222,10 @@ const EnvironmentsPage: FC = () => {
const newEnvs = [...environments];
newEnvs.splice(i, 1);
newEnvs.splice(i - 1, 0, e);
await apiCall(`/organization`, {
await apiCall(`/environment/order`, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a net new endpoint for this? Should we simply allow the plural endpoint to also update the order?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ultimately broke it out into a separate endpoint as the permission logic for each of these is different.

For re-ordering, the user only needs to have permission to create environments globally, or in at least 1 project. Whereas, if the user is updating the actual environments, they need create/update permission for every endpoint passed in.

If we added this to the plural endpoint, the logic would get really complicated. We'd need to do a deep comparison of the environments being passed in to see if the user was just trying to update the order, or update the actual environments.

Ultimately, it felt like it would lead to bugs, and was easily handled by breaking the logic out into two separate endpoints.

Copy link
Contributor

@romain-growthbook romain-growthbook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now! Maybe once the integration tests basic stuff drops we could consider adding tests for those endpoints as well.

@mknowlton89 mknowlton89 merged commit 18c87e2 into main May 30, 2024
3 checks passed
@mknowlton89 mknowlton89 deleted the mk/remove-env-update-from-putOrganization branch May 30, 2024 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants