Skip to content

Address types - use of 'alternative' and requirement of 'type' #725

@kathryn-ods

Description

@kathryn-ods

Following discussion in openownership/lib-cove-bods#123

Currently there's a normative requirement 'If an address in the addresses array is of type "alternative" then there is also another address in the array'

There's 2 possible edge cases here:

  • two addresses with 'alternative'
  • one address with no 'type' and one with 'alternative'

it's made me think that 'alternative' is just an unhelpful code. We should probably turn it into 'other', make the field required and reduce constraints. I can't see that loosening constraints would open up any particular loophole wrt BO verification. (For example, I don't imagine that red-flagging would depend on categorisation of addresses: if a BODS statement from one source categorised an entity's address as 'business' but the same entity's address in another source was categorised as 'other' that would not be of great interest. The address itself is the target of interest.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions