SpiceDB

Current Schema

/* Access encodes Dgraph's AccessProfile-Permission */
definition access {
	relation has: role | team
	relation misses: role | team
	permission grant = has + has->grant
	permission deny = misses + misses->grant
}

/** Resources ** */
/**
 * Application resources - Insert on Dgraph and create relationships using its data*
 */
/*
 * 1) Vitalflex
 * ** 1.1) IdentityManager (add to Dgraph) -
 * **** 1.2.1) Schemas
 * **** 1.2.2) Identities
 * **** 1.2.3) IdentityAssociation
 * **** 1.2.4) groups
 * **** 1.2.5) HealthcareServices
 * **** 1.2.6) AccessProfiles
 * **** 1.2.7) Applications
 * *******
 * ** 1.2) Elsa (add to Dgraph) -
 * **** 1.2.1) Server
 * **** 1.2.2) Dashboard
 * **** 1.2.3) Backend
 * ** 1.3) KafkaUI (add to Dgraph) -
 * ** 1.4) MeshPlaygroud (add to Dgraph?) -
 * ** 1.5) OperationsDashboard (add to Dgraph) - OD does not use Dgraph data. Replicate current resources as application components (in our Dgraph everything is an application)
 * **** 1.5.1) Pages
 * ****** 1.5.1.1) Addressprint -
 * ****** 1.5.1.2) Diagnostics -
 * ****** 1.5.1.3) Endpoints -
 * ****** 1.5.1.4) Finance -
 * ****** 1.5.1.5) Groups -
 * ****** 1.5.1.6) Home - Rename to "Overview" -
 * ****** 1.5.1.7) Logistics -
 * ****** 1.5.1.8) Odootickets -
 * ****** 1.5.1.9) Organizations -
 * ****** 1.5.1.10) Quality control -
 * ****** 1.5.1.11) Quickscan reports -
 * ****** 1.5.1.12) Reports -
 * ****** 1.5.1.13) Settings -
 * ****** 1.5.1.14) Support -
 * ****** 1.5.1.15) Worklist -
 * ****** 1.5.1.16) Announcements -
 * **** 1.5.2) Controllers -
 * ****** 1.5.2.1) Controller Reportfile -
 * **** 1.5.3) LegacyPages
 * ****** 1.5.3.1) Device -
 * ****** 1.5.3.2) Device statistics -
 * ****** 1.5.3.2) Measurement statistics -
 * **** 1.5.4) Features
 * **** 1.5.4.1) Notifications
 * **** 1.5.4.2) UseExperimentalSettings
 * ** 1.6) ProcessManager aka Workflow (add to Dgraph) -
 * **** 1.6.1) MainTasks
 * **** 1.6.2) Support
 * **** 1.6.3) Clinic
 * ** 1.7) Dgraph (add to Dgraph)
 * **** 1.7.1) Server
 * **** 1.7.2) Features
 * ****** 1.7.1.1) AddAction
 * ****** 1.7.1.2) DeleteAction
 * ****** 1.7.1.3) QueryAction
 * ****** 1.7.1.4) UpdateAction
 * ** 1.8) UI Manager
 * ** 1.9) HRV Manager
 * **** 1.9.1) Features
 * ****** 1.9.1.1) Update scores
 * **** 1.9.2) Pages
 * ****** 1.9.1.1) Analysis
 * ****** 1.9.1.2) Sports
 * ** 1.10) Grafana
 * **** 1.10.1) Features
 * ****** 1.10.1.1) EditAction
 * ****** 1.10.1.2) ViewAction
 * ** 1.11) SpiceDB
 * 2) CardiacNavigator -
 * 3) CardioflexPortal -
 * 4) Respiflex Portal -
 * 5) Respiro Analyst -
 */
// Note: don't forget to read relationships from left to right. E.g.: accessprofile is admin of application
// Note2: for permissions with an arrow (check application definition) I read it like this: who has accesss to admin can_admin the application + who has can_admin permission to the has_component can_admin the application
// Note3: has_component is the inverse of "PartOf" on Dgraph
definition application {
	// child
	relation has_component: application
	relation to_read: access
	relation to_modify: access
	permission modify = to_modify->grant + has_component->modify - to_modify->deny
	permission read = modify + to_read->grant + has_component->read - to_read->deny
}

definition migration {
	relation aka: migration
}

definition role {
	relation gets: user
	permission grant = gets + gets->grant
}

/* Generic type group to represent Dgraph's */
definition team {
	relation member: user
	relation manager: user
	relation participant: role
	relation director: role
	relation partof: team
	permission grant = member + member->grant + manager + manager->grant + participant + participant->grant + director + director->grant + partof + partof->grant
}

/** Subjects - entities that use our services** */
/* User */
definition user {
	relation relatedidentity: user
	relation primaryidentity: user
	permission grant = relatedidentity + primaryidentity + relatedidentity->grant
}