[KULRICE-8870] Cross-Page Validation Created: 31/Jan/13  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development, Roadmap, User Experience (UX)
Affects Version/s: 2.2
Fix Version/s: Backlog
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Major
Reporter: William Washington (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: 4 weeks
Time Spent: Not Specified
Original Estimate: 4 weeks

Issue Links:
relates to KRRM-141 KRAD Phase 3 - Complete core features... Resolved
is related to KULRICE-8109 View validation server-side (ViewVali... Closed
Epic Link: Components
Rice Module:
KRAD Feature Area:
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required


Brian S: we don't mark pages that have errors. we mark tabs, but not navigation tabs.

If you're doing an Ajax submit, the page is sent to the server (the default). Only the fields on the page is validated b/c those are hte only ones that are rendered (in the DOM). If the view level is submitted, then the entire view is sent to the server.

The client-side validation has the option validates the page, and then the controller has the option of doing a view validation. if there is a view validation error, a message can come back indicating that there is an error on the other page, but no indication of where it is, b/c those fields on the other page aren't renderd in the DOM. This error could arise when you leave a page that has a validation error, and then submit the view from another page.

Navigating from page to page shows a dirty field indicator, but you can leave the page with invalid data, and data is not cleared (the data is still in the session). When a user navigates back to the page, no validation errors are shown, and the invalid data is still there.

View Validation Service (a.k.a. server-side validation - useful to check that data sent from client is actually accurate, and not messed with via ajax; sort of a security check; also helps ensure that any required fields from other pages are saved.) - jira exists (submitted by Brian) to only validate the page so that you don't get errors on other pages.

JIRA needed to address scenario when there are errors on other pages (if the controller called the view validation service before saving. currently no default on what the controller does (can save all view, just page, or part of page)). Brian believes Maintenance Docs just saves without doing a validation call.

Current behavior when an "unmatched" field comes back it's something like "<propertyname>: required".

Comment by William Washington (Inactive) [ 01/Feb/13 ]

Additional background:

Garey Taylor: KS devs using “validation decorators” - these call the datadictonary method.

  • says we’re not calling validate.view method from w/in ENR.
  • we do validate the view, but it’s done manually.
    • form is “pulled apart” and individual parts of the form are validated.
      • e.g. only like terms can be rolled over.
    • validation service by default uses datadictionary validation.
    • “validation decorator” is only in KS, and that’s part of the service infrastructure.
      • includes datadictonary validation just before the it “hits the service layer”
      • some issues found when things that are valid in db aren’t valid for view.
      • Action: William to check with Bonnie/Venkat if there are errors found via the validation decorator, we are likely not able to give specific field-level error messages.
  • if the validateXYZ() method is called, it returns a list of failures on a field by field basis. If this method is skipped and the app goes directly to create/update, then a DataValidationException is thrown but might not have the detail
  • Haroon: perhaps Brian can give suggestion of where it’s improperly used.
Comment by Garey Taylor [ 04/Feb/14 ]

I think my comment was taken out of context. Ie. I was not talking about Cross-Page validation.

Generated at Sun Jan 24 11:35:03 CST 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.