HAS_EMAIL Party Data
Description
Connects a :Party, :Venue, or :EventSeries to a :Email.
Label
:HAS_EMAIL
Valid nodes
| From | Relationship | To | Cardinality |
|---|---|---|---|
| Party A node with the :Party label | HAS_EMAIL | Email A node with the :Email label | 0..n |
| EventSeries A node with the :EventSeries label | HAS_EMAIL | Email A node with the :Email label | 0..n |
| Venue A node with the :Venue label | HAS_EMAIL | Email A node with the :Email label | 0..n |
Properties
HAS_EMAIL uses the standard relationship properties.
CREATE
All :Email nodes have a primary property. There can be one and only one active primary email address for a given type attached to a party. It is acceptable that a party may have multiple email addresses of one type with none specifically being marked as primary.
If property primary is true, and the relationship property active is true, then all other active and primary email addresses of the same type must have the primary property set to false. If no prior email address exists for a given type, then the first email address created for that type must have primary set to true.
If the relationship property active is true, and the type and email are exactly the same as an existing active email address for this party, then the request is REJECTED. It is acceptable to have the same email assigned to a different type. For example, this could be used to indicate the a "Work" email address for a party is the same as the party's "Home" email address.
There is no limit to the number of active email addresses in any type.
UPDATE
Most updates to existing email addresses should be REJECTED in favor of deactivation and create flow as described above, so as to preserve the history of changes. To update an email address, deactivate the existing relationship and create a new :Email node and active relationship.
However, there are some situations where we will need to change an email address on an existing :Email node because of typographic error and where holding on to the original phone number would not be appropriate. In all cases before, the only properties that may be changed are email and the API update operation should be limited to data management (DMO) personnel. If updating a email of any type, the ACID transaction be to update email and modified properties.
DELETE
For email addreses, the DELETE verb corresponds to deactivating the relationship between the party and the :Email node. No physical deletes will happen.