bcgov / bcgov/entity

Legal API - Upgrade to python 3.13 and use common lear packages (model, etc.)

Open
#33,184 0 comments 0 reactions 0 assignees View on GitHub
Entities Team
Dominant language
JavaScript
Stars
23
Forks
62
Avg merge
24m
Merged PRs (30d)
1

Description

## Background
- During the GCP migration the other lear backend services were upgraded to python 3.13, but the legal-api is still on 3.9
- Several pieces of code were extrapolated out of the legal-api into common packages which are used in the other lear backend services, but the legal-api is not using them. Currently when we need to update these we have to update it in both the legal-api and the common packages, and there is some drift accumulating. The major concern here is the db model

## Plan for tickets
- ~Remove minio references in the legal-api (everything should be using DRS now)~ - *can't remove - still relying on it for a few flows*
- Remove db-versioning FF in the legal-api (it is on in all environments and the common model does not support dual versioning) - *confirmed with argus we can do this*
- Use common code packages instead of local copy - *need to discuss upgrading python before or after this - currently not all common packages support python 3.9*
- maybe new release branch with legal-api on python 3.13 with upgraded deps
- use business-registry-common
- will replace local legal-api copies of: BaseEnum, BaseMeta, datetime, LegislationDatetime
- update business-registry-common for any missing functionality
- common LegislationDatetime needs format_as_report_string_with_custom_time, format_as_report_expiry_string_1159, format_as_legislation_date, is_future
- update legal-api imports and verify
- small update / low risk
- use business-registry-account
- will replace AccountService used in legal_api/services/bootstrap.py
- update business-registry-common to include 'get_contacts' first
- small update / low risk
- use business-registry-model
- replaces the legal-api's models
- will need to take a close look at any drift across the two and apply updates to the common model as needed (i.e. recently a minor update to share_class in legal-api was not applied to business-registry-model)
- alembic migration versions should be in sync - need to verify how the CD is upgrading the db and update it if needed
- major update / high risk
- use business-registry-dissolution
- replaces InvoluntaryDissolutionService inside legal_api/services/involuntary_dissolution.py
- note: has model dependency and flags dependency should be reviewed
- use business-registry-digital-credentials
- replaces services/digital_credentials*.py in legal-api
- ~~may be some drift between valid_role_types and ALLOWED_DBC_ACCOUNT_ROLES to reconcile~~ [LO: unified this in https://github.com/bcgov/lear/pull/4390]
- note: has model dependency
- Release plan (Testing plan etc.)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the legal-api service paths named in the plan, especially legal_api/services/bootstrap.py, legal_api/services/involuntary_dissolution.py, and services/digital_credentials*.py, then compare their local implementations with the common packages. Verify Python 3.13 dependencies, model drift, db-versioning removal, and Alembic synchronization. Done means the legal-api uses the common packages and the release and testing plan is confirmed.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, databases
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.