feat: DIA-870: Add ModelInterface model/api #5347
Conversation
✅ Deploy Preview for label-studio-docs-new-theme ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for heartex-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5347 +/- ##
===========================================
+ Coverage 75.88% 76.00% +0.11%
===========================================
Files 154 159 +5
Lines 12931 12989 +58
===========================================
+ Hits 9813 9872 +59
+ Misses 3118 3117 -1 ☔ View full report in Codecov by Sentry. |
| ) | ||
|
|
||
| def get_queryset(self): | ||
| return ModelInterface.objects.filter(organization_id=self.request.user.active_organization_id) |
There was a problem hiding this comment.
Is this how we manage which, for example, projects a user sees? Is it based solely on the organization they're in? Maybe better question: is it possible for there to be a project inside an org I belong to that I can't see?
There was a problem hiding this comment.
No in projects lands there are multiple layers
Lets start with datasets land - this is closer to what we will have here
If user is an admin or owner, they see all datasets in the org
Otherwise, they will see datasets they are a member of. Since we do not have these requirements defined, for now I am returning all models of an org for all users, very easy to add the granularity later on.
Datasets example: https://github.com/HumanSignal/label-studio-enterprise/blob/develop/label_studio_enterprise/datasets/api.py#L121
| serializer.is_valid(raise_exception=True) | ||
|
|
||
| # we need to save these fields for faster access and filters without excess joins | ||
| serializer.validated_data['organization'] = self.request.user.active_organization |
There was a problem hiding this comment.
Similar question here to above: do we set this for projects based on the current org too?
There was a problem hiding this comment.
Not sure what you mean exactly, but yes we set the org field of a project, or a dataset, to the org that a user is in while creating the object
| ) | ||
|
|
||
| def has_permission(self, user): | ||
| return True # TODO - which roles have access by default? |
There was a problem hiding this comment.
should we add an AC or anything in the follow up ticket to do something more principled here?
There was a problem hiding this comment.
I will make a ticket to pin down requirements on permissions of models, its not clear yet
|
This lgtm, but wanted to ask before "approving": which branch did you want this to live in for now? Just on this one, or a more general "prompter" type branch? |
|
Closing in favor of #5388 |
PR fulfills these requirements
[fix|feat|ci|chore|doc]: TICKET-ID: Short description of change madeex.fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errorsChange has impacts in these area(s)
(check all that apply)
Describe the reason for change
(link to issue, supportive screenshots etc.)
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)
What level of testing was included in the change?
(check all that apply)
Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)