Skip to content

28971 Document Record Service Common Utils#3624

Merged
argush3 merged 7 commits intobcgov:mainfrom
flutistar:28971-drs-utils
Jul 18, 2025
Merged

28971 Document Record Service Common Utils#3624
argush3 merged 7 commits intobcgov:mainfrom
flutistar:28971-drs-utils

Conversation

@flutistar
Copy link
Contributor

@flutistar flutistar commented Jul 4, 2025

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).

Copy link
Collaborator

@doug-lovett doug-lovett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Collaborator

@kialj876 kialj876 Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@kialj876 kialj876 Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function has been renamed, and corresponding unit tests have been added.

@flutistar
Copy link
Contributor Author

This PR is ready for review.

@flutistar
Copy link
Contributor Author

I have several follow-up PRs pending, so I’d appreciate it if this could be reviewed at your earliest convenience.

@BrandonSharratt
Copy link
Collaborator

I approved, with the caveat that as it is this will not address the LEAR use case

Comment on lines +35 to +48
"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,
Copy link
Collaborator

@argush3 argush3 Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

image

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@argush3 argush3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@flutistar
Copy link
Contributor Author

flutistar commented Jul 18, 2025

Thanks Argus, This ticket is intended to cover the missing document types, this will be handled in follow-up PRs.

@argush3 argush3 merged commit 90d730b into bcgov:main Jul 18, 2025
1 check passed
@severinbeauvais severinbeauvais changed the title Document Record Service Common Utils 28971 Document Record Service Common Utils Aug 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants