Closed sienna-oldaccountdontuse closed 10 months ago
@ozamani9 @jinghualicgi - This is a priority1, moving it over to to-do for SRE.
I could not reproduce the issue in DEV. @sienna-blumstengel can you reproduce the issue? Thanks
@lmcclung to ask home team BAs to replicate this type of NR and then try registration in COLIN.
Note from Jenn:
The error that is being generated for this issue is occurring when the filing is attempted in Colin and not in the names system, so I don’t have an example to send. I’m sorry I can’t confirm the exact error message.
@sienna-blumstengel - Any updates after connecting with the home team?
Sounds like Patty doesn't have any more information than I do, I will reach out to her again and see if I miscommunicated
Patty sent these screenshots from when issues were happening. I just looked in NameX today...:
Hi Patty, Thanks for the screenshots! I just searched NR 0859496 and NR 4251706 in NameX, it looks like they were able to use it and register successfully? Have you seen this issue occur recently?I don't see anything unusual in the console, I was hoping to see an error message. Sorry for the delay on this, thanks for your help! Sienna
Emailed staff with update March 28
https://app.zenhub.com/files/157936592/fd17f8f9-27c5-46c2-9b03-b0eb3d1bc866/download
Leaving this for next week.
@lmcclung - To check what email updates she has on this.
Linda will follow up
I tested again in DEV environment:
Everything looks good to me.
namex UI showed different from what in the description. I wonder if the bug has been fixed?
@mdinu1961 to follow up with @lmcclung for a way to reproduce this.
Steps to reproduce the issue in DEV:
I opened an enhancement ticket 11716 and will get UX eyes on it for how to improve the user experience so they don’t submit the NR without checking. Might be simplest to hide the ‘submit this name without checking’ for extraprovincial name requests.
colin log:
2022-05-18 08:18:49,639: (, anon, REGS2, dummy) ERROR[axis14.NameRequestServiceAxis14] NameRequestServiceAxis14.getStatus failed:
org.apache.axis2.AxisFault
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at ca.bc.gov.registries.nro.ws.client.axis14.NewNameRequestServiceStub.fromOM(NewNameRequestServiceStub.java:948)
at ca.bc.gov.registries.nro.ws.client.axis14.NewNameRequestServiceStub.GetStatus(NewNameRequestServiceStub.java:349)
...
Caused by: java.lang.RuntimeException
at ca.bc.gov.bcregistryservices.www.nro.services.VARCHAR_30.setVARCHAR_30(VARCHAR_30.java:63)
at ca.bc.gov.bcregistryservices.www.nro.services.VARCHAR_30$Factory.parse(VARCHAR_30.java:417)
at ca.bc.gov.bcregistryservices.www.nro.services.GET_STATUS_RESPONSE$Factory.parse(GET_STATUS_RESPONSE.java:987)
at ca.bc.gov.bcregistryservices.www.nro.services.GetStatusResponse$Factory.parse(GetStatusResponse.java:394)
at ca.bc.gov.registries.nro.ws.client.axis14.NewNameRequestServiceStub.fromOM(NewNameRequestServiceStub.java:914)
@lmcclung I dug into the error and found out the real cause of the error. (see my second test case). I will ask Patty to take care of it if an extraprovincial company name can exceed 30 characters. Meanwhile, before 11716, do I need to fix the error in my first test case by removing the corp number value after entering a corp name? so that in colin, corp number field leave blank in the case.
colin calls getStatus and the homeJurisNum in the response isn't correct. homeJurisNum should be null. The homeJurisNum is retrieved from request_instance table.
<GetStatusResponse>
<errors />
<nrNumber>NR 3254587</nrNumber>
<findStatusCode>SUCCESS</findStatusCode>
<nameRequestStateCode>A</nameRequestStateCode>
<approvedName>PATTY CRACKED TO CODE TEST LTD.</approvedName>
<expiryDate>2022-05-24</expiryDate>
<xproJurisdiction>ALBERTA</xproJurisdiction>
<homeJurisNum>PATTY CRACKED TO CODE TEST LTD.</homeJurisNum>
</GetStatusResponse>
if the extraprovincial name input correctly, the get status response is like below and no errors in colin:
<GetStatusResponse>
<errors />
<nrNumber>NR 4864398</nrNumber>
<findStatusCode>SUCCESS</findStatusCode>
<nameRequestStateCode>A</nameRequestStateCode>
<approvedName>EVE TEST 11380 NAME OVER 30 2 LTD.</approvedName>
<expiryDate>2022-07-13</expiryDate>
<xproJurisdiction>ALBERTA</xproJurisdiction>
</GetStatusResponse>
Work around execute the following script in namesp:
update request_instance ri
set ri.home_juris_num = null
where ri.request_id=
(select request_id
from request r
where r.nr_num = 'NR xxxxxxx');
@lmcclung Linda, please let us know your decision who to proceed, thanks
@jinghualicgi Hello, we will pass the two options by the Business team in our requirements meeting tomorrow, and plan to have a final answer for you by tomorrow afternoon. @lmcclung @eve-git
@Mihai-QuickSilverDev any update regarding this ticket? Thanks
@Mihai-QuickSilverDev @lmcclung any update regarding this ticket? Thanks
Following-up with this ticket @lmcclung @Mihai-QuickSilverDev
@davemck513
Make it visible on entities board, and assign to David and Mihai for entities' input
@davemck513 @Mihai-QuickSilverDev any update regarding this ticket? Thanks
The ticket can be closed.
Describe the bug in current situation After #8558 was released, this bug was introduced.
8558 only implemented the ability for clients to see the HJ number in NameX. Not sure why this change has prevented clients from using the NR. Maybe this is an unrelated issue?
From Jenn, INC0148511
Impact of this bug High impact, prevent clients from using their NRs, and staff can't do a workaround so they need to completely remake their NR. Lots of effort.
Chance of Occurring (high/medium/low/very low) High chance of occurring for XPRO BC NRs and we can't validate the number so we ask then to enter the name. Of all the XPRO NRs in BC - I think that is a decent amount
Steps to Reproduce
Expected behavior This NR should be usable in COLIN