21760 stage 1 overdue ARs notification #2823
Conversation
...rvices/entity-emailer/src/entity_emailer/email_processors/ar_overdue_stage_1_notification.py
Outdated
Show resolved
Hide resolved
...rvices/entity-emailer/src/entity_emailer/email_processors/ar_overdue_stage_1_notification.py
Outdated
Show resolved
Hide resolved
…age_1_overdue_ARs_notification
| if etype == 'bc.registry.dissolution': | ||
| identifier = email_msg.get('identifier', None) | ||
| furnishing_id = email_msg['data']['furnishing']['furnishingId'] | ||
| business = ar_overdue_stage_1_notification.get_business_by_furnishing_id(furnishing_id) | ||
| if business.legal_type in ['BC', 'ULC', 'CC', 'BEN']: | ||
| source = email_msg.get('source', None) | ||
| return create_message_context_properties(etype, message_id, source, identifier, False) | ||
| return create_message_context_properties(etype, None, None, None, False) |
There was a problem hiding this comment.
This is not required as we are not sending the queue message to the emailer from the filer.
When it's sent from the filer, we are using the already existing format which does not provide a unique "id" that can be used. This why everything except etype == "bc.registry.names.request" is constructing a unique id based off of the incoming properties of a queue message.
We can just extend the check above for if etype == 'bc.registry.names.request': to include a check for bc.registry.dissolution
| # Update corresponding furnishings entry as PROCESSED | ||
| etype = email_msg.get('type', None) | ||
| if etype and etype == 'bc.registry.dissolution': | ||
| furnishing_id = email_msg['data']['furnishing']['furnishingId'] | ||
| ar_overdue_stage_1_notification.update_furnishing_status(furnishing_id, | ||
| Furnishing.FurnishingStatus.PROCESSED) |
There was a problem hiding this comment.
this should not be part of tracker code.
it should take place in the processor
There was a problem hiding this comment.
I am not sure how to detect the HTTP status of notify API in the Processor. 😢
There was a problem hiding this comment.
please rename this processor to involuntary_dissolution_stage_1_notification.py
There was a problem hiding this comment.
Please rename file to INVOL-DIS-STAGE-1.html
| # Update corresponding furnishings entry as FAILED | ||
| etype = email_msg.get('type', None) | ||
| if etype and etype == 'bc.registry.dissolution': | ||
| furnishing_id = email_msg['data']['furnishing']['furnishingId'] | ||
| ar_overdue_stage_1_notification.update_furnishing_status(furnishing_id, | ||
| Furnishing.FurnishingStatus.FAILED) | ||
|
|
There was a problem hiding this comment.
this should not be part of tracker code.
should take place in processor
There was a problem hiding this comment.
I am not sure how to detect the HTTP status of notify API in the Processor. 😢
So, I implemented this feature in update_message_tracker
There was a problem hiding this comment.
I think what you can do is add a try/catch block around send_email in worker.py
If there is no exception thrown, you can assume it sent the email successfully.
if an error is thrown then you can mark it as failed and re-throw the error so the original error handling logic can run.
In both instances, maybe a new function named something like involuntary_dissolution_stage_1_processor.post_process can be called
| @@ -142,6 +143,9 @@ def process_email(email_msg: dict, flask_app: Flask): # pylint: disable=too-man | |||
| elif etype and etype == 'bc.registry.bnmove': | |||
| email = bn_notification.process_bn_move(email_msg, token) | |||
| send_email(email, token) | |||
| elif etype and etype == 'bc.registry.dissolution': | |||
There was a problem hiding this comment.
can we add a check to confirm the data.furnishingName is one of the following:
- DISSOLUTION_COMMENCEMENT_NO_AR
- DISSOLUTION_COMMENCEMENT_NO_TR
- DISSOLUTION_COMMENCEMENT_NO_AR_XPRO
- DISSOLUTION_COMMENCEMENT_NO_TR_XPRO
| # run worker | ||
| with patch.object(AccountService, 'get_bearer_token', return_value=token): | ||
| with patch.object(worker, 'send_email', return_value='success') as mock_send_email: | ||
| with patch.object(ar_overdue_stage_1_notification, 'get_recipient_from_auth', return_value='[email protected]'): |
There was a problem hiding this comment.
don't think this is required anymore if we get the email recipient from the furnishings record
| 'furnishing': { | ||
| 'type': 'PROCESSING', | ||
| 'furnishingId': furnishing.id, | ||
| 'furnishingName': furnishing.furnishing_name |
There was a problem hiding this comment.
please verify, the processor only processes the four furnishing types i mentioned in a comment above
| # get business | ||
| furnishing_id = email_info['data']['furnishing']['furnishingId'] | ||
| furnishing = Furnishing.find_by_id(furnishing_id) | ||
| business = get_business_by_furnishing_id(furnishing_id) |
There was a problem hiding this comment.
please create a separate PR and add a relationship to the furnishing model so you can just access the business using furnishing.business.
Issue #: /bcgov/entity#21760
Description of changes:
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).