-
Notifications
You must be signed in to change notification settings - Fork 10.8k
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
feat(API): Add user management endpoints to the Projects Public API #12329
base: master
Are you sure you want to change the base?
Conversation
packages/cli/src/public-api/v1/handlers/projects/spec/paths/projects.projectId.yml
Show resolved
Hide resolved
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
…-delete-users-from-project
3c650ef
to
e9d96f5
Compare
…-delete-users-from-project
…-delete-users-from-project
… personal projects with the public API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if the public API DTOs should be in it's own folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if the public API should define their own DTOs. We don't want to give the public API more power by accident when we add more power to the internal API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should definitely keep all public API DTOs in the public-api folder, since they don't need to be shared with editor-ui. but we can do that later in another PR.
userId: z.string(), | ||
role: projectRoleSchema, | ||
userId: z.string().min(1), | ||
role: projectRoleSchema.exclude(['project:personalOwner']), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've excluded the project:personalOwner
here too. Personal projects are special, they can only have one owner with that role. There should not be any API endpoint that allows changing the relation. They are created when the user is created and deleted when the user is deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've temporarily reverted this change, to make the build pass again.
Since there is a a lot more projects related types that are still duplicated between packages, I'd like to clean this up later in a separate PR as well.
throw new ProjectNotFoundError(projectId); | ||
} | ||
|
||
// TODO: do we need to prevent project owner from being removed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't, as long as this function only works with team projects.
TODO: add test to make sure this function throws when used on a personal project.
throw new ProjectNotFoundError(projectId); | ||
} | ||
|
||
// TODO: do we need to block any specific roles here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this function also should only work with team projects and should disallow the personalOwner role.
TODO: add test for this
…-delete-users-from-project
@@ -23,6 +23,8 @@ import { License } from '@/license'; | |||
import { CacheService } from './cache/cache.service'; | |||
import { RoleService } from './role.service'; | |||
|
|||
type Relation = { userId: string; role: ProjectRole }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we not use the ProjectRelation
from @n8n/api-types
@@ -299,7 +364,13 @@ export class ProjectService { | |||
}); | |||
} | |||
|
|||
async addUser(projectId: string, userId: string, role: ProjectRole) { | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to revert the changes to this method to fix the test, but the changes did make sense. I'll try to fix this and add additional tests next week.
Summary
Adds the ability to add and delete users to and from projects using the public API endpoint:
Also allow the ability to alter user roles in projects.
Note: There were problems getting the integration test server to work when I referenced the
projectId.yml
schema within the OpenAPI spec rather than inlined it. As we'll be looking to improve the public API at some point in the future, I've moved all the references to inline instead.Related Linear tickets, Github issues, and Community forum posts
Partially fixes: PAY-1852
Review / Merge checklist
release/backport
(if the PR is an urgent fix that needs to be backported)