-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix: LEAP-634: Actualize label config validation #5313
base: develop
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for heartex-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for label-studio-docs-new-theme ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
464e4ff
to
4fc649c
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5313 +/- ##
===========================================
- Coverage 75.88% 75.79% -0.10%
===========================================
Files 154 154
Lines 12931 12930 -1
===========================================
- Hits 9813 9800 -13
- Misses 3118 3130 +12 ☔ View full report in Codecov by Sentry. |
label_studio/core/label_config.py
Outdated
@@ -84,7 +84,7 @@ def parse_config_to_json(config_string): | |||
if xml is None: | |||
raise etree.ParseError('xml is empty or incorrect') | |||
config = xmljson.badgerfish.data(xml) | |||
config = _fix_choices(config) | |||
# config = _fix_choices(config) |
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.
Is this intentionally left in? Why don't we want to _fix_choices
anymore?
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.
nevermind, I see this was mentioned in the description - my feeling is that if we really don't need this we can delete the line (?)
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 don't know that much about this label config validation code, and don't feel extremely confident approving without doing a sync review to understand its impact better. Is there anyone else more familiar with this who could take a look?
I will say we probably don't want to check in a commented-out function call; one way forward would be to remove the line and add a comment like
# previously we called `_fix_choices` here, but no longer need to because...
@jombooth Thanks for that! It looks much better. |
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.
LGTM, if someone more knowledgeable can do a second look that'd be great but I think we should get this over to QA, and the changes look reasonable!
This PR is stale because it has been open 45 days with no activity. Remove |
This PR is stale because it has been open 45 days with no activity. Remove |
Config validation didn't take into account many tags and their attributes. This PR might fix this.
It also fixes nested
Choice
validation.It also will fix validation messages. (Usually there is no path at all and sometimes it doesn't tell about the problem itself)
PR fulfills these requirements
Explain the changes you've made
exc.path
intoexc.absolute_path
fixes displaying validation paths fromValidation failed on :
toValidation failed on View/Labels/Label:
.into
fixes displaying cause of validation fails from
OrderedDict() is not of type 'array'
to something more meaningful like'value' is a required property
# config = _fix_choices(config)
was hidden under the comment due to the problem, which caused this workaround, was solved by json schema itself.
What alternative approaches were there?
Fixing displayed paths has leaded to the situation when
shows
View/Choices/Choice/0
, butshows
View/Choices/Choice
. And previously it was justChoice/0
in this case.To make it more consistent we can use removed right now function
_fix_choices
but convert all tags into arrays and in the same time get rid ofMaybeMultiple*
rules in schema. But so far it doesn't look to me that it's necessary, 'cause doesn't really affects user's navigation.This change affects (describe how if yes)
Does this PR introduce a breaking change?
It depends on the validity of the validation rules.
What level of testing was included in the change?
Which logical domain(s) does this change affect?
Labeling Interface