VSN-1965 : Refactoring the validation process to cover saving validator email & validation date as well as making the validated user email distinguished & Resolving the issue of empty representatives email during individual saving.

Merge Request – Validator Email Integration, Signature Mechanism, and Saving Flow Enhancements

Overview

This Merge Request introduces an extended evolution of the prepared passenger validation workflow by incorporating validator identity, adding a unique signature mechanism tied to the validation process, and improving the robustness and correctness of the saving and exception handling logic. Additionally, supporting documentation and build configuration updates are included to align the system with a remote release environment.

The objectives of this MR are:

• Enable traceable and identifiable validation actions.
• Establish a mechanism to generate a unique signature once a passenger is validated.
• Make validated passenger records observable through signature-based identification.
• Improve error handling and data reliability during the saving process.
• Ensure consistent build dependencies and accurate documentation.

---

Scope of Changes

1. feat(validation): Defining validator email

Introduces a new attribute to capture the validator email within the validation process.

Details:

• Added the validatorEmail field as part of the validation logic.
• Ensures that each validation event is associated with a specific validator identity.
• Provides a foundation for traceability and future audit requirements.

Outcome:

• Validator identity becomes a first-class component of the validation workflow.

---

2. feat(validation): Adding validator as a param

Extends the validation request handling to include the validator email as an input parameter.

Details:

• Introduced validatorEmail as a required request parameter for validation calls.
• Ensures that the backend service receives explicit validator information rather than deriving it implicitly.

Outcome:

• Creates a consistent and explicit contract across the validation chain.

---

3. feat(validation): Adding signature method

Implements a utility method responsible for generating a unique signature once validation occurs.

Details:

• Introduced a method dedicated to generating a signature for a validated passenger.
• Signature generation is linked to the passenger email to make the result deterministic and unique.
• Designed for extensibility in future features such as validation certificates or audit tokens.

Outcome:

• Establishes the groundwork for identity-based validation marking.

---

4. feat(validation): Signature logic

Applies the newly introduced signature mechanism to validated passengers.

Details:

• Integrates signature logic directly into the validation process.
• Once validation completes, the passenger receives a signature value, making their validation status externally observable.
• Creates an identifiable marker to distinguish validated passengers from unvalidated ones in a verifiable way.

Outcome:

• Validated passengers can now be uniquely recognized through their signature.

---

5. doc(changelog): Changelog update

Updates documentation to reflect recent technical and functional changes.

Details:

• Recorded all new validation-, signature-, and configuration-related modifications in the changelog.

Outcome:

• Documentation is aligned with current implementation.

---

6. fix(pom): Setting common from local snapshot to remote release

Updates build configuration for dependency correctness.

Details:

• Switched from a local snapshot dependency to a remote released version.
• Ensures consistency across environments and prevents local version drift.

Outcome:

• Builds become more reliable and aligned with deployment environments.

---

7. refactor(saving): Passenger saving

Improves error handling in the prepared passenger saving workflow.

Details:

• Enhanced exception handling by extracting and exposing the actual HTTP response message.
• Allows more accurate feedback and debugging during failure scenarios.

Outcome:

• Clearer error visibility and improved maintainability.

---

8. feat(saving): New test in saving

Introduces an additional logical check during the saving process.

Details:

• Added a condition to nullify representative emails when blank values are provided.
• Ensures no meaningless empty email values are persisted.

Outcome:

• Results in cleaner stored data and reduces potential inconsistencies.

---

Impacts

Functional

• Validation actions are now explicitly tied to a specific validator identity.
• Validated passengers have a unique signature, enabling deterministic identification.
• Saving operations benefit from improved error visibility and data hygiene.

Technical

• The validation workflow gains new parameters, utilities, and logic layers.
• Build configuration is aligned with remote release infrastructure.
• The saving mechanism now adheres to stricter data-handling rules.

---

Backward Compatibility

• Previous validation operations without validator information require adaptation.
• No breaking changes to existing data structures, but downstream dependencies must recognize the new signature behavior.

---

Recommendations

• Persist validator identities and signatures into a dedicated history store.
• Display validator identity and signature in UI validation result screens.
• Introduce validation auditing or reporting based on signature metadata.

---

Conclusion

This MR significantly enhances validation transparency, traceability, and observability while strengthening the saving process and aligning the environment with remote deployment standards. It lays the foundation for further compliance, auditing, and lifecycle management features for validated passengers.

Closes VSN-1965