Skip to content

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

Closed
wants to merge 19 commits into from
Closed

Conversation

Gabefire
Copy link
Collaborator

@Gabefire Gabefire commented Oct 10, 2024

Description

  • This works similar to user groups
  • Need to find a clever way to test this since it looks like staging orgs only have current users and you can not edit current user
  • Unable to test deleting users for obvious reason
  • All test run locally and deleting works locally

Type of change

Please delete options that are not relevant.

  • New feature (non-breaking change which adds functionality)

All Submissions

  • Have you followed the guidelines in our Contributing document?
  • Have you provided a description?
  • Are your changes properly formatted?

New Feature Submissions

  • Does your submission pass tests?
  • Have you added thorough tests for your new feature?
  • Have you commented your code, particularly in hard-to-understand areas?
  • Have you added a Docstring?

@Gabefire Gabefire added the hold do not review yet! label Oct 10, 2024
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())
Copy link
Collaborator Author

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):
Copy link
Collaborator

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?

Copy link
Collaborator Author

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):
Copy link
Collaborator

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.

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 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

Copy link
Collaborator Author

@Gabefire Gabefire Oct 14, 2024

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,
Copy link
Collaborator Author

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

@Gabefire Gabefire marked this pull request as ready for review October 14, 2024 17:44
@Gabefire Gabefire requested a review from a team as a code owner October 14, 2024 17:44
@Gabefire Gabefire added hold do not review yet! and removed hold do not review yet! labels Oct 14, 2024
@Gabefire Gabefire marked this pull request as draft October 17, 2024 18:43
@Gabefire Gabefire closed this Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hold do not review yet!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants