Use field level validation errors
What does this MR do and why?
The Group Reporting Settings page uses bootstrap form errors.
This MR refactors that to pajamas style field level validation errors.
Issue: https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/47
Screenshots or screen recordings
Before | After |
---|---|
![]() |
![]() |
How to set up and validate locally
Follow the steps outlined in this MR to test this locally.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
changed milestone to %15.2
added devopsanti-abuse featureaddition groupanti-abuse sectionsec typefeature labels
assigned to @alexbuijs
Suggested Reviewers (beta)
The individuals below may be good candidates to participate in the review based on various factors.
You can use slash commands in comments to quickly assign
/assign_reviewer @user1
.Suggested Reviewers @mayra-cabrera
,@dbalexandre
,@dzaporozhets
,@marin
,@tigerwnz
If you do not believe these suggestions are useful, please apply the label Bad Suggested Reviewer. You can also provide feedback for this feature on this issue:
https://gitlab.com/gitlab-org/gitlab/-/issues/357923
.Automatically generated by Suggested Reviewers Bot - an experimental ML-based recommendation engine created by ~"group::applied ml".
Edited by GitLab Reviewer-Recommender Bot1 Warning featureaddition and featureenhancement merge requests normally have a documentation change. Consider adding a documentation update or confirming the documentation plan with the Technical Writer counterpart.
For more information, see:
- The Handbook page on merge request types.
- The definition of done documentation.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Zamir Martins Filho ( @zmartins
) (UTC-4, 6 hours behind@alexbuijs
)Alexandru Croitor ( @acroitor
) (UTC+3, 1 hour ahead of@alexbuijs
)frontend Minahil Nichols ( @minahilnichols
) (UTC-4, 6 hours behind@alexbuijs
)Natalia Tepluhina ( @ntepluhina
) (UTC+2, same timezone as@alexbuijs
)test for spec/features/*
Zamir Martins Filho ( @zmartins
) (UTC-4, 6 hours behind@alexbuijs
)Maintainer review is optional for test for spec/features/*
UX Becka Lippert ( @beckalippert
) (UTC-4, 6 hours behind@alexbuijs
)Amelia Bauerly ( @ameliabauerly
) (UTC-7, 9 hours behind@alexbuijs
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
Dangermarked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
added featureenhancement label and removed featureaddition label
added UX label
- Resolved by Alexandru Croitor
Hi @vij! Could you review backend please?
Hi @minahilnichols! Could you review frontend please?
Hi @mnearents! Could you review UX please?
requested review from @vij, @minahilnichols, and @mnearents
Allure report
allure-report-publisher
generated test report!review-qa-blocking:
test report for a07274c0expand test summary
+-----------------------------------------------------------------------------------------+ | suites summary | +------------------------------------+--------+--------+---------+-------+-------+--------+ | | passed | failed | skipped | flaky | total | result | +------------------------------------+--------+--------+---------+-------+-------+--------+ | Protect | 2 | 0 | 0 | 2 | 2 | ❗ | | Plan | 47 | 0 | 1 | 47 | 48 | ❗ | | Manage | 38 | 0 | 2 | 40 | 40 | ❗ | | Create | 23 | 0 | 2 | 23 | 25 | ❗ | | Verify | 12 | 0 | 1 | 12 | 13 | ❗ | | Secure | 2 | 0 | 0 | 2 | 2 | ❗ | | Version sanity check | 0 | 0 | 1 | 0 | 1 | ➖ | | Feature flag handler sanity checks | 9 | 0 | 0 | 9 | 9 | ❗ | | Configure | 0 | 0 | 1 | 0 | 1 | ➖ | | Package | 0 | 0 | 1 | 0 | 1 | ➖ | +------------------------------------+--------+--------+---------+-------+-------+--------+ | Total | 133 | 0 | 9 | 135 | 142 | ❗ | +------------------------------------+--------+--------+---------+-------+-------+--------+
- Resolved by Alex Buijs
@alexbuijs backend looks good to me
from the linked issue...
We should be using field level validation errors, as this big red error is a legacy variation we want to be phasing out. Let me know if you'd like me to mock something up quickly!
I wonder if this has been discussed on how to phase out at a wider scale anywhere, do you happen to know? if we're going to refactor a load of haml forms to use a new input validation, perhaps there's a form helper we can build instead to make this less repetitive
but then again, perhaps there's no point if we're eventually moving everything over to Vue... which might explain why the
form_errors
helper has apajamas_alert
option.Perhaps we should be using that as an interim solution that involves less changes?
e.g.
= form_errors(@group.namespace_settings, pajamas_alert: true)
which results in:
Regardless, these are just some musings I had whilst reviewing - none of it is blocking, technically this works locally and looks good to me (just concerned about having to implement this sort of change across the board
)
removed review request for @vij
@vij
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline has been started.
For more info, please refer to the following links: