Skip to content
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.

Sign up for GitHub

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

Jump to bottom

UISACQCOMP-159: fix A user can not save edited PO line issue #713

Merged
merged 3 commits into from
Sep 6, 2023
Merged

UISACQCOMP-159: fix A user can not save edited PO line issue #713

merged 3 commits into from
Sep 6, 2023

Conversation

alisher-epam
Copy link
Contributor

Purpose

UISACQCOMP-159 - A user can not save edited PO line when budget without expense class was selected

Approach

  • Prevent submit if the fields are not valid.
Screen.Recording.2023-08-30.at.7.53.39.PM.mov

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

  • I've added appropriate record to the CHANGELOG.md
  • Does this PR meet or exceed the expected quality standards?
    • Code coverage on new code is 80% or greater
    • Duplications on new code is 3% or less
    • There are no major code smells or security issues
  • Does this introduce breaking changes?
    • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
    • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

  • What other modules will these changes impact?
  • Do JIRAs exist to update the impacted modules?
    • If not, please create them
    • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
    • Do they have all they appropriate links to blocked/related issues?
  • Are the JIRAs under active development?
    • If not, contact the project's PO and make sure they're aware of the urgency.
  • Do PRs exist for these changes?
    • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

@github-actions
Copy link

github-actions bot commented Aug 30, 2023 •
edited
Loading

Jest Unit Test Statistics

    1 files  ±0  139 suites  ±0   3m 14s ⏱️ +5s
370 tests +3  369 ✔️ +3  1 💤 ±0  0 ❌ ±0 
371 runs  +3  370 ✔️ +3  1 💤 ±0  0 ❌ ±0 

Results for commit 1f0c2e1. ± Comparison against base commit 79ab128.

This pull request removes 2 and adds 5 tests. Note that renamed tests count towards both. 
FundDistributionFieldsFinal should call beforeSubmit validation on submit form ‑ FundDistributionFieldsFinal should call beforeSubmit validation on submit form
FundDistributionFieldsFinal should call validateRequired onBlur fundDistribution selection ‑ FundDistributionFieldsFinal should call validateRequired onBlur fundDistribution selection

FundDistributionFieldsFinal should call beforeSubmit validation with required = false for expanseClass field on submit form ‑ FundDistributionFieldsFinal should call beforeSubmit validation with required = false for expanseClass field on submit form
FundDistributionFieldsFinal should call beforeSubmit validation with required = false for value field on submit form ‑ FundDistributionFieldsFinal should call beforeSubmit validation with required = false for value field on submit form
FundDistributionFieldsFinal should call beforeSubmit validation with required = true for expanseClass field on submit form ‑ FundDistributionFieldsFinal should call beforeSubmit validation with required = true for expanseClass field on submit form
FundDistributionFieldsFinal should call beforeSubmit validation with required = true for value field on submit form ‑ FundDistributionFieldsFinal should call beforeSubmit validation with required = true for value field on submit form
FundDistributionFieldsFinal should call validateRequired for fundId selection ‑ FundDistributionFieldsFinal should call validateRequired for fundId selection

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Aug 30, 2023 •
edited
Loading

BigTest Unit Test Statistics

0 tests  ±0   0 ✔️ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit 1f0c2e1. ± Comparison against base commit 79ab128.

♻️ This comment has been updated with latest results.

@sonarcloud
Copy link

sonarcloud bot commented Aug 31, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

10.0% 10.0% Coverage
0.0% 0.0% Duplication

@alisher-epam alisher-epam requested review from a team August 31, 2023 13:21
zburke
zburke reviewed Aug 31, 2023
View reviewed changes
Copy link
Member

@zburke zburke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, it's hard to reconcile the info in Jira ("Expected Results: Changes were successfully saved") with the info in the PR description here ("Prevent submit if the fields are not valid") since the latter basically restates the problem but claims it's a solution 😅 .

As I understand the changes, they use the beforeSubmit final-form attribute to prevent submission of the form if a required attribute is missing a value. Do these new beforeSubmit functions do something the ordinary validation functions couldn't?

@alisher-epam
Copy link
Contributor Author

Sorry, it's hard to reconcile the info in Jira ("Expected Results: Changes were successfully saved") with the info in the PR description here ("Prevent submit if the fields are not valid") since the latter basically restates the problem but claims it's a solution 😅 .

As I understand the changes, they use the beforeSubmit final-form attribute to prevent submission of the form if a required attribute is missing a value. Do these new beforeSubmit functions do something the ordinary validation functions couldn't?

Basically, it prevents the form from being submitted if the values are missing. In our case, although there is an error require message the form was saved. I think the behavior is associated with this library react-final-form-arrays and it can't prevent the form from being saved.
Honestly, it was difficult to come up with this solution. @zburke I was thinking, maybe we should think about moving to another more industry-standard form library such as formik or react-hook-form. Of course, this is a suggestion based on the current trends comparison 😅

zburke
zburke approved these changes Sep 1, 2023
View reviewed changes
Copy link
Member

@zburke zburke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, we're on the same page.

maybe we should think about moving to another more industry-standard form library such as formik or react-hook-form. Of course, this is a suggestion based on the current trends comparison 😅

Totally totally agree. Replacing redux-form with final-form felt like a great choice when we made it in 2018 since the migration path was much smaller than refactoring to formik and react-hook-form didn't even exist yet. But in retrospect, yeah, npm-trends shows it was a terrible choice. We don't have a specific plan, but migrating is on our radar.

@alisher-epam alisher-epam merged commit 3a3c0f2 into master Sep 6, 2023
@alisher-epam alisher-epam deleted the UISACQCOMP-159 branch September 6, 2023 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Dmytro-Melnyshyn Dmytro-Melnyshyn Dmytro-Melnyshyn approved these changes

@zburke zburke zburke approved these changes

@usavkov-epam usavkov-epam Awaiting requested review from usavkov-epam

@mariia-aloshyna mariia-aloshyna Awaiting requested review from mariia-aloshyna

@Terala-Priyanka Terala-Priyanka Awaiting requested review from Terala-Priyanka

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@alisher-epam @zburke @Dmytro-Melnyshyn