Update Schema with NR Data

shahriar-khan-fw commented 4 years ago

Description

Create sub-schema for Name Request data.
Update NR reference in Filings schema.
Add/update Python tests for schema changes.

The schema is used to validate that the data structure and values are correct.

In addition, we will need to add validators based on the business requirements for Names Request (eg, valid states or dates that we accept) -- this is ticket #2467.

Requirements

[x] talk to Lorna about what GET NR response looks like (completed on Feb 3, 2020)
[ ] talk to Lorna about what SEARCH NR response looks like

See story for requirements docs.

VALIDATION

Supported NR statuses only
- Conditionally approved (Must have Conditions/Consent status as: consent received)
- Approved
Non-expired NRs
Supported request types only
- Incorporation
Supported Conditions/Consent statuses only
- Received

severinbeauvais commented 4 years ago

@LJTrent said she would implement this.

severinbeauvais commented 4 years ago

Lorna and I discussed this and came up with the following. (We will discuss Search later.)

Get NR by NR Number

// may be Request with Type=NAME

Response (will be JSON):

{
  request {
    nr_num: 
    request_action: only incorporate if this is NEW (this used to be Request Type)
    entity_type: BC or CP
    state_cd: code for status
      // we accept APPROVED and not Consumed (corp_num does not exist)
      // we accept APPROVED and not Expired (expiration date <= today) and not Consumed
        *** valid until midnight (23:59:59) on expiration date ***
      // we accept CONDITIONAL with Consent Received and not Consumed
    state_desc: description for code
    consent_flag: YES, NO or R(eceived) // we only accept R
    corp_num: if exists then name is consumed
    expiration_date: format? (UTC ie yyyy-mm-dd hh:mm:ss-07 or -08)
    last_update: date of last change (yyyy-mm-dd hh:mm:ss-07 or -08) but this may reflect changes we don't care about
    ... // don't case about extra stuff
  }
  names [{ // may be several names, only 1 that is completed/approved
    name
    ... // don't case about extra stuff
  }]
  applicant {
    last_name
    first_name
    middle_name
    client_first_name // do we need this? @forgeuxGH5 to determine
    client_last_name // do we need this? @forgeuxGH5 to determine
    addr_line_1 // street address
    addr_line_2
    addr_line_3 // how do we map this?
    city
    postal_cd
    state_province_cd
    country_type_cd // CA
    email_address
    phone_number
    ... // don't case about extra stuff
  }
}

Note that the Incorporation app also needs to prompt for Name Translation (true/false) and an unlimited number of input fields. This is not strictly part of the NR schema and should therefore be stored separately in the incorporation filing object.

severinbeauvais commented 4 years ago

PS Scott mentioned that, in addition to the basic NR info in the initial mockups, we would probably add a button to display ALL the NR info available. Therefore, we will probably care about the extra fields in the schema after all.

sienna-oldaccountdontuse commented 4 years ago

Oh interesting, thanks @severinbeauvais! @forgeuxGH5 can we meet to add the other data to the requirements docs and tickets?

cameron-eyds commented 4 years ago

Can confirm that we have a sub schema for NameRequest data.

https://github.com/bcgov/business-schemas/blob/master/src/registry_schemas/schemas/name_request.json

However some properties will most likely needed to added when we migrate from our MVP model to a finalized Name Request flow upon NR's completion.

Closing this ticket, we have decided to create another ticket when time comes to handle these updates.

bcgov / entity