DEPARTED_TO Party-to-Party

Description

Describes what agency a client went to after that party left UTA

Label

:DEPARTED_TO

Valid nodes

From	Relationship	To	Cardinality
Party Party with a :HAS_ROLE relationship to a :Role {name: "Client"}	:DEPARTED_TO	Party Party with a HAS_ROLE relationship to a :Role { name: "Agency" }	0..n

Properties

DEPARTED_TO uses the standard relationship properties.

CREATE

If the...	...party node is...	The ACID transaction should be...
To	not an organization with an active Agency role	Reject A party can only depart to another party with a :Role { name: "Agency" }
To	United Talent Agency	Reject A party can not leave UTA for UTA
From	not a person or organization with a Client role	Reject A party can only come from another party with a :Role { name: "Client" }

We should not enforce any sequencing of the timeline of DEPARTED_TO relationships. We expect our data here is currently very spotty and thus it may be difficult to create the full picture without leaving gaps or overlaps in the sequencing. We will therefore allow authorized users to create any DEPARTED_TO relationships they wish, as long as they meet the business rules described above. It is very possible users will create duplicate and overlapping relationships. This is a tradeoff we will make in order to encourage data collection.

The active relationship property should be set to true as default on all CREATES. In inactive DEPARTED_TO relationship indicates a deletion.

TIP

Application developers are encouraged to make the timeline sequencing for this relationship very visible to the end user, so they will be motivated to correct it.

UPDATE

Updates are freely allowed for authorized users, with the exception of any change to the relationship properties id and active.

DELETE

On a DELETE the relationship should be deactivated with the termReason and thruDate required. Note that it is not semantically correct to say the DEPARTED_TO relationship "ended" on a certain date -- only the fromDate makes sense. Therefore, a deactivated relationship is treated as a deletion and the deactivated relationships should not be shown in most applications.

Examples

A client leaves for another agency

// Note in this example we are requiring the client and the
// agency to have active roles. This isn't really required;
// it may make sense to add a DEPARTED_TO relationship for 
// former clients, or from agencies that are no longer in business.

MATCH       (client:Party { id: $id })
        -   [:HAS_ROLE { active: true }]
        ->  (:Role { name: "Client" })
MATCH       (agency:Party { id: $agencyId })
        -   [:HAS_ROLE { active: true }]
        ->  (:Role { name: "Agency" })
MERGE       (client)-[newRel:DEPARTED_TO { 
              id: randomUuid(),
              subType: "",
              active: true,
              private: false,
              fromDate: $fromDate,
              thruDate: "",
              termReason: ""
            }]->(agency)
RETURN      newRel{.*}