FIX - Entity type for new Societies NR set to Null

[oanyahuru]

This was noticed while testing #20142 yesterday towards the afternoon. Prior to that, the error did not appear. It is also occuring in prod and leading to some confusion for clients. When a new NR for a society is created, it appears that the entity type for the NR is set to null instead of SO for society.

This ultimately results in errors when the letters are being generated, for next steps the users are being directed to Forms

They should instead be directed to Societies

[ozamani9gh]

https://app.zenhub.com/workspaces/names-team-board-new-655554cbddd49510027dad2e/issues/gh/bcgov/entity/20142

[ozamani9gh]

@oanyahuru can you confirm this is still an issue.

[EPortman]

Not able to recreate this issue.

In NameRequest UI, to make a societies NR one must leave the page to bcregistry.ca/societies. So NameRequest UI is not connected with Society NRs.

[EPortman]

Seems like this is an issue with the legacy app. Name Request properly sends _entity_type_cd to the API when submitting a NR which the API adds to database correctly.

It may be something like the legacy app is not sending the field correctly.

[EPortman]

Confirmed the API is working fine

• Made a Post Request using Postman of a Society
• Postgres DB correctly displays type SO and not null

[ozamani9gh]

@Mihai-QuickSilverDev can you reach out to Home Team. Fix needs to be applied there.

[Mihai-QuickSilverDev]

@MKagis @droberts27 Good Morning Michael, David, the issue described in this ticket was identified as pertaining to one of the Home Team Systems - hence I am forwarding it here to you. Please see details presented above. Please let us know if there is anything that the BCROS Team could provide for this issue. Thank you!

[MKagis]

@ozamani9gh @Mihai-QuickSilverDev @oanyahuru

A few questions from my end:

• I note, in her initial description of this issue, that Oge reports that this issue was discovered "yesterday" - but that was a month ago - and previous to that point, it sounds like the entity type = SO was being properly populated. When was this problem discovered? What date? Specifics in a case like this help with diagnosis.
• Along the same vein, what was the last NR that was created where the entity type was correctly populated? Again, Oge's initial description seems to suggest that this data problem is new. When, in PROD, did it start?
• Ethan's comment from last week indicates that he started in the Name Request UI before going to bcregistry.ca/societies, which is Societies Online. What happens if an end user bypasses Name Request and goes straight to Societies Online?

[Mihai-QuickSilverDev]

@oanyahuru Hi Oge, would you be able to comment on Michael's points above? Thanks much! @ozamani9gh

[MKagis]

Hi again,

Thayne and I have just done some testing on the societies side of things and we can see that the data is created in the legacy application and database just fine. For NR 5141584, we see REQUEST_TYPE_CD=SO in the legacy database. Therefore, the described issue is not a problem with the legacy application, Societies Online, but with how the data is transferred to the modern infrastructure.

This situation makes the answers to my questions about when this issue started even more important. The home team has not make any changes to how NRs are created. Have there been any changes to the modern databases or to process that syncs the data to modernized infrastructure? There is no data problem on the legacy side.

[fodiley]

@oanyahuru , @Mihai-QuickSilverDev , @ozamani9gh If tickets still need to be reviewed can we not move them to done. It was in the done column this morning. Can we have the person who is to review to this ticket do so

[fodiley]

@MKagis this was moved to done by the PO Omid in error because our coop told us it was done. We will be reviewing this ticket and see how it can reviewed.