DMP-4366: Add and adjust admin portal API validations

[Ben-Edwards-cgi]

Links

Jira

Change description

Summary of Git Diff

This Git diff outlines various updates made to multiple OpenAPI YAML files. The changes primarily involve the addition of maxLength, minimum, and maximum constraints for several fields across different components, enhancing the validation of input data.

Highlights

• audio.yaml:

  • Added maxLength: 64 to courtroom_name.

• audiorequests.yaml:

  • Added minimum: 1 and maximum: 2147483647 to media_request_id.
  • Added maxLength: 32 to case_number.
  • Added maxLength: 2000 to owner and requested_by.

• cases.yaml:

  • Added maxLength: 64 to courtroom_name.

• courthouse.yaml:

  • Added maxLength: 255 to courthouse_name in two locations.

• event.yaml:

  • Added maxLength: 64 to courtroom_name.

• hearings.yaml:

  • Added maxLength: 64 to courtroom_name.

• transcriptions.yaml:

  • Added minimum: 1 and maximum: 2147483647 to transcription_id.
  • Added maxLength: 32 to case_number.
  • Added maxLength: 2000 to owner and requested_by in multiple sections.

Does this PR introduce a breaking change? (check one with "x")

[ ] Yes
[X] No

[karen-hedges]

Should there be tests to show the endpoints fail if the size of whats constrained fails?

[Ben-Edwards-cgi]

We could create dedicated tests to confirm the constrains are hit successfully, however this seems redundant as we use a third party library to manage all of this for us as such as long as the swagger is accurate the validation should work as the library would have there own tests to verify all the validation is applied correctly

[jackmaloney]

We could create dedicated tests to confirm the constrains are hit successfully, however this seems redundant as we use a third party library to manage all of this for us as such as long as the swagger is accurate the validation should work as the library would have there own tests to verify all the validation is applied correctly

@Ben-Edwards-cgi just discussing with Karen, do you not want an integration test(s) to make sure the application behaves as expected when one of these limits is exceeded?

[Ben-Edwards-cgi]

We could create dedicated tests to confirm the constrains are hit successfully, however this seems redundant as we use a third party library to manage all of this for us as such as long as the swagger is accurate the validation should work as the library would have there own tests to verify all the validation is applied correctly

@Ben-Edwards-cgi just discussing with Karen, do you not want an integration test(s) to make sure the application behaves as expected when one of these limits is exceeded?

@jackmaloney As this is an ingres point for the application rather then an endpoint we consume, our application does not care about the response, we would just chuck a 400 for the FE to handle in the same way we handle all other schema validation failures. So I don't think there is much if any additional value gained for adding additional tests for this.

[davet1985]

We could create dedicated tests to confirm the constrains are hit successfully, however this seems redundant as we use a third party library to manage all of this for us as such as long as the swagger is accurate the validation should work as the library would have there own tests to verify all the validation is applied correctly

@Ben-Edwards-cgi just discussing with Karen, do you not want an integration test(s) to make sure the application behaves as expected when one of these limits is exceeded?

@jackmaloney As this is an ingres point for the application rather then an endpoint we consume, our application does not care about the response, we would just chuck a 400 for the FE to handle in the same way we handle all other schema validation failures. So I don't think there is much if any additional value gained for adding additional tests for this.

I don't think it's worth adding tests to test the swagger constraints, we have tests on the frontend to check the implementation there and the backend constraints are a fallback. As we are simply adding configuration, swagger should be behaving as specified. I know there's always a risk that it might not, but the risk here is tiny.