-
Notifications
You must be signed in to change notification settings - Fork 68
Added a member model to manage users better #1864
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
Conversation
project_memberships: Set[ProjectMembership] = Field(default=set()) | ||
can_access_all_projects: bool = Field(default=False) | ||
default_role: Optional[Role] = Field(default=None) | ||
user_group_ids: Set[str] = Field(default=set()) |
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.
Avoided making this user group objects since it would sort of get out of control.
from labelbox import Client | ||
|
||
|
||
class ProjectMembership(_CamelCaseMixin): |
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.
There is already exist some sort ProjectRole
class for the same purpose. Can't that be refactored and re used? Otherwise SDK once again would have similar methods/classes for the same purpose. Or is there plan to deprecate the former?
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.
class ProjectMember(DbObject): |
This won't work for this class since the relationships are off. Plus, ProjectRole and ProjectMemberships are technically two different objects in our backend.
} | ||
|
||
|
||
class Member(_CamelCaseMixin): |
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.
SDK already have class User. What would be the difference? Can be User
class just refactored to have more fields and support for new methods? Otherwise there is again this weird state where SDK going to have two types to represent the same object.
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 attempted this it does not work since we have to use a GetMemberRework call to make sure we get all the fields including ProjectMemberships. We also need to setUserAccess Call which is not supported by the built in entities user groups had a similar issues
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.
Also this is 100% experimentally by definition can be deleted and removed any time. We should deprecate user objects if we decided to remove Members from experiments but right now the SDK is severally lacking on member management so for Alignerr for example i have to heavily use GQL direclty
"search": search, | ||
"roleIds": [role.uid for role in roles] if roles else None, | ||
"groupIds": group_ids, | ||
"complexFilters": None, |
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.
These complexFilters are associated with Alignerr and can be added to support getting members based on filters
Description
Type of change
Please delete options that are not relevant.
All Submissions
New Feature Submissions