28971 Document Record Service Common Utils#3624
Conversation
doug-lovett
left a comment
There was a problem hiding this comment.
Looks good so far. You may want to remove unused document classes. The max allowed files size could be an env variable.
| current_app.logger.info(f"Error on deleting document {e}") | ||
| return {} | ||
|
|
||
| def get_document(self, request_info: RequestInfo) -> dict: |
There was a problem hiding this comment.
I think this name is misleading as you are 'searching' for a document. I would expect the 'get_document' to retrieve the document by document id (a different drs endpoint which is also used by the legal api - similar to update/delete).
Also, will this document exist in the lear db documents table if it exists? Just wondering if it makes more sense to check the db and then retrieve the document via the id. This would also allow you to get the pdf directly by passing 'application/pdf' in the headers to drs instead of getting the url first and then making another call for the pdf
There was a problem hiding this comment.
Actually, I am just realizing that everything in here is using a different set of endpoints meant for 'document class' logic so this can stay as is. I think we'll probably just have 2 different DRS classes because there isn't much overlap ('documents/...' endpoints vs 'application-reports/...' endpoints). We can look at it later and probably make a base class for that each one extends
There was a problem hiding this comment.
Thank you, that makes sense — checking the lear DB first before making the API call is a good approach. However, for the search functionality, there are some DRS records that don’t have an associated document record (e.g. we create a DRS record for staff filings to capture the barcode number). So for the download function, I’m going to check the LEAR DB instead.
| dt = datetime.now(timezone.utc) | ||
| return dt.strftime("%Y-%m-%dT%H:%M:%S.%f")[:-3] + "Z" | ||
|
|
||
| def post_document(self, request_info: RequestInfo, file: bytes = None, has_file: bool = True) -> dict: |
There was a problem hiding this comment.
We're also posting to DRS for generated filing documents at a different endpoint so I think we should rename this so that when we add the other one in here it still makes sense. I think renaming this to 'post_class_document' would make sense?
The other endpoint is more general and covers all types of documents under any product/some entity/some identifier (i.e. filing id)/document name. I think it will more sense to have it as the 'post_document' because it isn't tied to lear logic / will be used by other apis. Just thinking of the future because its likely we'd split this class out later and then extend it here for the lear specific things
There was a problem hiding this comment.
The function has been renamed, and corresponding unit tests have been added.
|
This PR is ready for review. |
|
I have several follow-up PRs pending, so I’d appreciate it if this could be reviewed at your earliest convenience. |
python/common/document-record-service/src/document_record_service/document_service.py
Outdated
Show resolved
Hide resolved
|
I approved, with the caveat that as it is this will not address the LEAR use case |
python/common/document-record-service/src/document_record_service/constants.py
Outdated
Show resolved
Hide resolved
python/common/document-record-service/src/document_record_service/constants.py
Outdated
Show resolved
Hide resolved
python/common/document-record-service/src/document_record_service/constants.py
Show resolved
Hide resolved
python/common/document-record-service/src/document_record_service/constants.py
Outdated
Show resolved
Hide resolved
| "amalgamationApplication": DocumentTypes.AMLG.value, | ||
| "amalgamationOut": DocumentTypes.AMLO.value, | ||
| "annualReport": DocumentTypes.ANNR.value, | ||
| "changeOfAddress": DocumentTypes.FRMA.value, | ||
| "consentAmalgamationOut": DocumentTypes.AMLO.value, | ||
| "consentContinuationOut": DocumentTypes.CNTO.value, | ||
| "continuationIn": DocumentTypes.CNTI.value, | ||
| "continuationOut": DocumentTypes.CNTO.value, | ||
| "conversion": DocumentTypes.CNVS.value, | ||
| "correction": DocumentTypes.CORR.value, | ||
| "courtOrder": DocumentTypes.CRT.value, | ||
| "registrarsNotation": DocumentTypes.REGN.value, | ||
| "registrarsOrder": DocumentTypes.REGO.value, | ||
| "systemIsTheRecord": DocumentTypes.SYSR.value, |
There was a problem hiding this comment.
I think DOCUMENT_TYPES is still missing a lot of entries if my understanding of how things are supposed to work is correct.
For example an incorporation application have the following documents available. I'm assuming we can ignore the receipt and it will be continue being retrieved via pay api?
I'm ok with approving this PR and fleshing this out as we go but this list will need to be exhaustive at the end of the day to cover all the document types.
I also think we need to include things like incorporationApplication, alteration and changeOfDirectors now as they are pretty common.
There was a problem hiding this comment.
We have a document type called System is the record. For any other documents not listed, the document type will be SYSR.
For better clarity, I’ll send you the spreadsheet link via direct message.
There was a problem hiding this comment.
As per our conversation, there will need to be some additional work done in subsequent PRs to ensure all the existing DOCUMENT_TYPE entries are accurate and any missing ones are added.
Things that should be addressed in subsequent PRs should include:
- are consent entries accurate? two entries map to CNTO
- does staff continuation authorization entry need to be added
- spreadsheet has missing document type entries for IA and other filings. if they are not SYSR, these entries will need to be added
- there are no entries in spreadsheet for firms. i'm assuming there will be non SYSR entries. if so they need to be added
argush3
left a comment
There was a problem hiding this comment.
approving with the understanding that subsequent updates will be made to ensure DOCUMENT_TYPES is accurate and includes all the required entries for all business types + filing types
|
Thanks Argus, This ticket is intended to cover the missing document types, this will be handled in follow-up PRs. |
Issue #: /bcgov/entity#28971
Description of changes:
This PR introduces utility functions for the Document Record Service (DRS) integration.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the lear license (Apache 2.0).