Name Examination UI - Build Resend Notification on each Notify Record.

[ozamani9gh]

For Each Notify record build a button to be able to resend email.

https://www.figma.com/file/zHZFygfAWSmNp6kDb7g1Zs/NameX-Design-Tickets?type=design&node-id=2-25&mode=design

[eve-git]

We have a notification_history table, but it does not store the email body. The email body needs to be regenerated based on the information we have. Here are the notification types and their required parameters:

• before-expiry: nr_num, expiration_date
• expiry: nr_num, expiration_date
• renewal: nr_num, expiration_date (after payment update)
• upgrade: nr_num (after payment update)
• refund: nr_num, refund, refund_value
• receipt: nr_id, payment_token, state_cd

Currently, I believe the problem is retrieving emails sent before NR renewal—the previous expiration dates need to be retrieved from the log. Additionally, the current notify-api does not support retrieving specific NR data from the notification_history table. I will open a ticket with the SRE team. Finally, displaying the email body in the UI is also a challenge. New functions will need to be created to ensure the email body appears in the UI. -- I wonder if it is possible to display only the parameters used to generate the email in the UI, instead of the entire email body?

[eve-git]

The UI design looks great. However, considering the implementation, is it possible to make some changes?

1. We don’t store the body of emails. To display the entire email in the UI, we would need to generate the email on the fly, and the email template is in the entity-queue project, which is better left untouched at this level. Instead, could the notification histories be displayed as a list with columns such as:

   

2. Additionally, I have concerns about retrieving historical data after edits. For example, if we resend a receipt after updating names, the NR name information in the receipt will reflect the current name information instead of what was in the original receipt. Is this acceptable?

[oanyahuru]

@eve-git I have reached out to the design team on your first question above. I have also contacted the examiners for their comments on the second point. I will keep you posted

[eve-git]

Support required from other apps:

1. BCRegistry-SRE/notify-api: To retrieve all the notification histories for a specific NR, a new api service is needed.
2. Entity-emailer: An NR payment notification includes name choices, which a user may update after payment. Currently, the name information is retrieved by the entity-emailer using the input nr_id. To ensure the email content remains consistent with the original, we need to pass the name information to the entity-emailer as well.

[oanyahuru]

@eve-git the design team has proposed a new design

The business also responded to your second question

[eve-git]

Namex has an events table. I am considering saving the NR states before sending the notification. The notification can then be retrieved by sending the NR states to the entity-emailer. I will discuss this possibility with the entity developer

[eve-git]

request the support from emailer to accept NR object as parameter: https://github.com/bcgov/entity/issues/21632 https://app.zenhub.com/workspaces/entities-team-space---new-65550db1fcfd2f002838a52a/issues/gh/bcgov/entity/21632