Indicate required fields in Experiment and Scoreset forms - #717
Open
davereinhart wants to merge 11 commits into
Open
Indicate required fields in Experiment and Scoreset forms#717davereinhart wants to merge 11 commits into
davereinhart wants to merge 11 commits into
Conversation
Introduce MvRequiredMarker, a shared span rendering a red asterisk with an "(required)" screen-reader label, and wire it into the label slots of MvFloatField, MvTagField, and MvUploadField via a new `required` prop. MvMarkdownField forwards `required` to MvFloatField and sets aria-required on the textarea; MvTagField does the same on its AutoComplete input.
Set `required` on the mandatory MvFloatField, MvMarkdownField, MvTagField, and MvUploadField instances across ExperimentFields, ScoreSetFields, ScoreSetContextFields, TargetFields, and VariantScoreFields, so their labels render the asterisk marker and the inputs expose aria-required. Wizard-mode help labels for radio-group and custom fields (target category, sequence type, reference sequence, scores file) get an explicit MvRequiredMarker since they have no MvFloatField label to hang it on. VariantScoreFields computes `scoresFileRequired` from `existingVariantCount`: editing a score set that already has variants keeps them when no new scores file is chosen, so the field is optional there.
Add a subtitle to the ExperimentCreator and ScoreSetCreator page headers noting that fields marked with an asterisk are required, so the markers rendered by MvRequiredMarker have a legend.
davereinhart
marked this pull request as draft
August 19, 2026 17:59
|
coverage: 10.271% (-0.003%) from 10.274% — feature/davereinhart/606/flag-required-fields into release-2026.3.0 |
davereinhart
marked this pull request as ready for review
August 20, 2026 15:39
bencap
reviewed
Aug 20, 2026
bencap
left a comment
bencap
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for working on this Dave! A few general notes in addition to the comments:
- The legend subtitle is only on the two creator screens. That should also go on the editor screens, since the asterisks will render there too.
- We should also apply this marker to
src/components/forms/KeywordFields.vuefor consistency. On line 67 of that file, we currently have a ternary operator to denote optional/required that this could replace.
For the question of what to do about the markers for entries without a float field, I think keeping them on the left is reasonable for now. Maybe eventually we can try to unify everything on a float field. The one thing I would do is just split out the help text and the detail so that the asterisk isn't on the full sentence. For example in field-descriptions.ts, category would become:
...
category: {
hint: 'The biological category of the target.',
help: 'Target category',
detail: 'The biological category of the target.'
},
...
The asterisk will then consistently appear on the field name, whether it renders in the help column or the data column.
Sets aria-required prop on FileUpload to support screen readers.
Set `required` on the target label field when the score set has multiple targets, which is when the API requires a label. In wizard mode the field only renders for multi-target sequence-based score sets, so it is always marked there; the flat editor also shows it for single-target score sets, where it stays optional. Move the sentence out of the `help` text for target category, sequence type, and reference sequence, leaving the field name in `help` and the sentence in `detail`. These three fields render their marker in the wizard help column rather than on a float label, so the asterisk now sits on the field name instead of a full sentence, matching how it reads everywhere else.
Set `required` on the score set and title fields, which the API rejects a calibration without: the create endpoint returns 422 with no score set URN, and `title` has no default. The classes file gets the same treatment for class-based calibrations, where the API demands a CSV on create and on update alike. That upload field hides its own label, so its marker goes on the wizard help label instead. Mark the publication sources on the same conditions the API applies. Method and threshold sources are required once the calibration defines functional classifications, and evidence sources once a classification carries ACMG evidence. Baseline-score-only calibrations are exempt from all three. Mark the baseline score while no functional classifications are defined. The ScoreSetCreator wizard gates its Next button on either a baseline score or at least one classification, so the marker moves between the baseline score and the source fields as the submitter fills the form, and the step's gate is no longer unexplained. Add a `showRequiredLegend` prop to CalibrationEditor so the three dialog hosts explain the marker they now render. ScoreSetCreator opts out, since its page header already carries the legend.
…or functional ranges Drop the required marker from the baseline score. The API treats it as optional: the column is nullable, the view model defaults it to None, and the only validator that reads it returns early when it is unset. The asterisk promised validation that never ran. Loosen the calibration step of the score set wizard to match. It gated Next on either a baseline score or at least one functional classification, so a submitter who wanted neither could not advance. The step now checks the title, which the API does require, and keeps the per-range checks on label and classification so an added range still has to be filled in. Also add required marker to label field for functional ranges.
davereinhart
force-pushed
the
feature/davereinhart/606/flag-required-fields
branch
from
August 21, 2026 18:19
210bc6a to
f453f6b
Compare
The API requires every functional classification to specify either a numeric range or a class name, and rejects one that provides both. For a class-based calibration the class name is therefore the required half of that pair, alongside the label. The field renders only in the class-based branch of the row, so the marker cannot appear on a range-based classification, where a class name would be a validation error rather than a requirement.
The classification toggle and the two range boundary inputs have no float label to hang a marker on, so it goes on their wizard help labels, the same way target category and the classes file field work. The boundary marker covers the pair rather than each input. A range-based classification has to define its range, but either end may be left unbounded, so a marker on an individual bound would claim more than the API enforces. The classification toggle has a default of not_specified, but it can be cleared: PrimeVue's SelectButton deselects on a second click, the wizard then blocks its Next button, and the API rejects an explicit null against that enum rather than falling back to the default.
bencap
reviewed
Aug 21, 2026
Comment on lines
+2
to
+4
| <div v-if="showRequiredLegend !== false" class="pb-3 text-sm text-text-muted"> | ||
| Fields marked <span class="font-bold text-danger">*</span> are required. | ||
| </div> |
Collaborator
There was a problem hiding this comment.
Not required for merge, but now that the legend is repeated across more than a couple files it might be worth its own simple component to prevent any drift. It's styled subtly differently in each location (but maybe that is intentional)?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a consistent and accessible way to indicate required fields in form components across the application. The main changes include adding a new
MvRequiredMarkercomponent, updating various form field components to support arequiredprop, and visually marking required fields in both labels and help texts.Required field indication and accessibility:
MvRequiredMarkercomponent that renders an asterisk and screen-reader-only "(required)" text for accessibility, and integrated it into form field labels where appropriate. [1] [2] [3] [4]MvFloatField,MvTagField,MvUploadField, andMvMarkdownFieldcomponents to accept arequiredprop and display the required marker in labels when set. [1] [2] [3] [4] [5] [6] [7] [8]aria-requiredattributes to relevant input elements for accessibility compliance. [1] [2]Form field usage updates:
ExperimentFields.vue,ScoreSetFields.vue,ScoreSetContextFields.vue, andTargetFields.vueto set therequiredprop on fields that are mandatory, ensuring both visual and semantic indication. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]TargetFields.vueto include the required marker for required fields. [1] [2] [3]These changes improve the user experience by clearly marking required fields and enhance accessibility for users relying on assistive technologies.