BFF delete organization #983
Conversation
| } | ||
|
|
||
| // Delete the organization from the database | ||
| if err = s.db.DeleteOrganization(org.UUID()); err != nil { |
There was a problem hiding this comment.
Note that we will need at least a confirmation prompt on the frontend, since deleting the organization record will completely delete the registration from the database.
| // Remove the organization from all collaborators so that they don't get an error | ||
| // when they try to log in. If a user no longer has an organization, they will be | ||
| // assigned one automatically the next time they log in. | ||
| for _, collab := range org.GetCollaborators() { |
There was a problem hiding this comment.
This is pretty tricky because we're relying on state in Auth0 to decide which organization to attempt to log the user into. If the organization is deleted out from under them, we need to have a way in which they can still login. For most users, what this means is that they will be assigned a new default organization on login. For TSP users who can be assigned to multiple organizations at once, we need to do a bit of extra work to figure out which organization to default them to.
There was a problem hiding this comment.
If GDS went down in the middle of this operation, could we end up with some collaborators who still have metadata for deleted orgs? If so, are there any places where you think this might cause problems?
There was a problem hiding this comment.
I think this would mostly cause problems when users try to login; in that case we might have to manually change things in Auth0 to make sure everything is in sync.
There was a problem hiding this comment.
Looks good @pdeziel ! I had just a few questions (probably resulting from the fact that I am not very familiar with the collaborators feature).
| return | ||
| } | ||
|
|
||
| // The user must be a collaborator in the organization to delete it |
There was a problem hiding this comment.
Is being a collaborator equivalent to having delete permissions on the user's claims from auth0 or does collaborator status include different types of permissions?
There was a problem hiding this comment.
The user will need the delete:organizations permission to get past the middleware to this endpoint. This is mainly a sanity check to make sure the user is actually in the organization (e.g. to protect against the frontend passing in the wrong orgID).
| // Remove the organization from all collaborators so that they don't get an error | ||
| // when they try to log in. If a user no longer has an organization, they will be | ||
| // assigned one automatically the next time they log in. | ||
| for _, collab := range org.GetCollaborators() { |
There was a problem hiding this comment.
If GDS went down in the middle of this operation, could we end up with some collaborators who still have metadata for deleted orgs? If so, are there any places where you think this might cause problems?
pkg/bff/docs/swagger.yaml
Outdated
| @@ -652,6 +652,34 @@ paths: | |||
| summary: Create a new organization [create:organizations] | |||
| tags: | |||
| - organizations | |||
| /organizations/{id}: | |||
| delete: | |||
| description: Completely delete an organization, including the registration and | |||
There was a problem hiding this comment.
Should we add a little note like "Warning! Deletes are not reversible! Be sure to prompt user for confirmation before executing."
Scope of changes
This adds a delete organization endpoint to the BFF API. The tricky part here is making sure users in that organization can still login to the frontend. For example, if a user's current organization is the one being deleted, we need to update their app metadata on Auth0 so that they default to a different organization (if available).
SC-11817
Type of change
Acceptance criteria
This endpoint should allow users with the
delete:organizationspermission to delete organizations that they are a collaborator on.Author checklist
Reviewer(s) checklist