JASPER-583/578: Court List Document Bundle

[ronaldo-macapobre]

Pull Request for JIRA Ticket: JASPER-583 and JASPER-587

Issue ticket number and link

https://jira.justice.gov.bc.ca/browse/JASPER-578
https://jira.justice.gov.bc.ca/browse/JASPER-583

Description

• Create a new Court List endpoint that creates a document bundle based on the selected appearance from Court List.
• The endpoint handles retrieving of saved binders and merging of the documents.
• Returns a list of binders and base64 string for UI to consume and display the PDF.
• Skipped old unit tests so we can run unit tests and determine if updates broke existing unit test or new ones are not passing at all.
• Updated GHA that runs the backend unit tests to use the correct working directory where the tests really are.

ℹ️ Marking this as ready for review since we don’t anticipate any major backend changes anymore. I’m also working on adding unit tests for the areas affected by this code change.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Local Testing via swagger

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[WadeBarnes]

The bundle retrieved for a court list, is that basically a list of the Judicial Binders and Key Documents Bundles/Binders for the files associated to the appearances on the court list, or is there more to it?

[ronaldo-macapobre]

The bundle retrieved for a court list, is that basically a list of the Judicial Binders and Key Documents Bundles/Binders for the files associated to the appearances on the court list, or is there mor to it?

Right now, it is only processing Key Document binders and skipping any Civil appearances. But yes, the response object returns the binders associated with the selected appearances and the base64 string of the merged documents from the binders.

[WadeBarnes]

The bundle retrieved for a court list, is that basically a list of the Judicial Binders and Key Documents Bundles/Binders for the files associated to the appearances on the court list, or is there mor to it?

Right now, it is only processing Key Document binders and skipping any Civil appearances. But yes, the response object returns the binders associated with the selected appearances and the base64 string of the merged documents from the binders.

In that case I would be more inclined to implement the interface on the binder API itself. It feels a bit off for the court-list to be fielding requests for binders.

The implementation for the binder endpoint would accept a list of contexts (collection of labels defining a context) and return a list of binders for each of those contexts. In this case the call would simply be a list of contexts defining the specific context for each of the appearances listed in the court list.

This brings up another thought; a context API and/or service that given an object (file, appearance, document, etc) returns the context (set of labels) for that object. This would ensure contexts are generated in a consistent manner. We also might want to consider including the context as a standard data element whenever we're passing data around, that way it's readily accessible whenever needed.

[ronaldo-macapobre]

The bundle retrieved for a court list, is that basically a list of the Judicial Binders and Key Documents Bundles/Binders for the files associated to the appearances on the court list, or is there mor to it?

Right now, it is only processing Key Document binders and skipping any Civil appearances. But yes, the response object returns the binders associated with the selected appearances and the base64 string of the merged documents from the binders.

In that case I would be more inclined to implement the interface on the binder API itself. It feels a bit off for the court-list to be fielding requests for binders.

The implementation for the binder endpoint would accept a list of contexts (collection of labels defining a context) and return a list of binders for each of those contexts. In this case the call would simply be a list of contexts defining the specific context for each of the appearances listed in the court list.

This brings up another thought; a context API and/or service that given an object (file, appearance, document, etc) returns the context (set of labels) for that object. This would ensure contexts are generated in a consistent manner. We also might want to consider including the context as a standard data element whenever we're passing data around, that way it's readily accessible whenever needed.

I was able to move the core logic of initializing the binders and document mergin to the BinderService. It is now being called via the BindersController. In the interest of time, I skipped some unit tests for now until the main logic is approved.

[ronaldo-macapobre]

Added more unit tests and some cleanup.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
4 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud