Validate phone and Email call is not checking for the correct Nr and Phone number.

[riyazuddinsyed]

Describe the bug in the current situation
when the user tries to add an NR while filing an Alteration with an invalid email ID, then the Validate Api call allows an NR with a different email ID without any validations.

Steps to reproduce the behavior:

1. Go to 'https://dev.edit.business.bcregistry.gov.bc.ca/BC0875385/alteration?accountid=2079'
2. Login with BCREGA001.
3. Search For 'BC0875385'
4. Start an Alteration Filing.
5. Now add 'NR 4573597' with any email id.
6. Observe that the API call does not throw any validations.

Screenshots/ Visual Reference/ Source

Impact on user:

• The NR would be accepted for any phone or email data entry.
• Could be confusing for the user.
• No security implications, the NR is secured by affiliation.

To Do List:

• Determine if this validation should be needed/used here.

[severinbeauvais]

I think this is a loophole -- if the subject NR is affiliated to the current account then the entered phone/email are not verified.

Should we change the code to always verify the phone/email (even if not needed)? (But we don't know ahead of time if they are needed.) @NaveenHebbale @yuisotozaki

If a change is needed, it's in the Legal API (where the call to validate a name request is handled).

PS Here's an example where the NR is not affiliated to my account, and I entered the wrong phone number:

[Mihai-QuickSilverDev]

@yuisotozaki Would you be able to express an opinion on this, please?

[yuisotozaki]

I think the core of this issue is making sure that the user has access of some kind to the NR at the time of filing.

Scenario 1: The user already has access to the NR. I.e. it's in their MBR.
In this case, I would remove the phone/email check entirely at the time the user enter the NR number in the alteration filing.

Scenario 2: An alteration draft was saved with an NR, then the NR was removed from the user's MBR.
In this case, since we don't know if the NR was removed from the user's MBR for security purpose, the safest option is to ask for email/phone in the draft.

Scenario 3: User starts an alteration and adds an NR that is not on their MBR. In this case, we do ask for email/phone to essentially have the user add the NR to their MBR.

[severinbeauvais]

After discussion with Yui and James, we feel that the current priority is good. This is a loophole but doesn't do anything bad or block the user or allow the user to use the wrong NR; we are simply asking the user for an email/phone that they might not really have to enter, and we might allow the wrong email/phone if the NR is already affiliated. Anyway, probably not a big deal.

A nice solution might be a 2-step process: first prompt for NR number and check it with the API, then if needed prompt for email/phone. This is a medium amount of work but it is in a complex component, for what it's worth.

@OlgaPotiagalova What is your decision on how to proceed with this?