Verify FSP ID entered by user against THE.FSP_AGREEMENT_HOLDER and THE.FOREST_STEWARDSHIP_PLAN

[amee99073]

As a Ministry FOM reviewer I want validation that ensures that the FSP id entered by the licensee when creating a new FOM is a valid FSP id and is an FSP administered by the same forest client as the one creating the new FOM So That I can be certain that the publicly available information in the FOM is completely correct and inadvertent errors have not been made

Additional Context FOM are not reviewed by the ministry until the final submission stage. It is quite possible for the individual entering the FOM data to accidentally enter an incorrect or invalid FSP ID in relation to any new FOM they create. FOM is not commected to the 'the' schema. As such it has no way to query this data other than via api. It is possible for the individual entering the new FOM data to accidentally associate their FOM to an FSP that is managed by a different client. On Publish, this data is put out into the public realm and is available openly to anyone. given the sensitivity and scrutiny that newly awarded cut blocks in the province are given, it may become an issue if unvalidated, incorrect data is displayed.

Acceptance Criteria

• When a new FOM is created, Then the FSP ID entered must be valid (must exist in the.FOREST_STEWARDSHIP_PLAN)
• When a new FOM is created, Then the combination of FSP ID entered and the Client number related to the user entering the data must be valid (combination must exist in the.FSP_AGREEMENT_HOLDER where the FSP id entered = FSP_AGREEMENT_HOLDER.FSP_ID and the client number associated to the user is the client number in FSP_AGREEMENT_HOLDER.CLIENT_NUMBER for the FSP ID entered)

Definition of Done

• [ ] Ready to Demo in Sprint Review
• [ ] Does what I have made have appropriate test coverage?
• [ ] Documentation and/or scientific documentation exists and can be found
• [ ] Peer Reviewed by 2 people on the team
• [ ] Manual testing of all PRs in Dev and Prod
• [ ] Merged

[gormless87]

Duplicates 278. Keeping 235 as it is more recent than 278. Sequence seems out of order as 278 was created in fingerprint repo and later transferred to fom repo.