Date: Thu, 28 Mar 2024 20:55:01 +0000 (UTC) Message-ID: <767999035.6999.1711659301388@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6998_397119145.1711659301387" ------=_Part_6998_397119145.1711659301387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Registry is a multi-tenant application (each CO is a tenant, and= the COmanage CO is a special tenant used to manage the platform), and as s= uch some thought should be given to how data is managed within and across t= enants.
Configurations that apply to the entire platform (eg: a default theme) s= hould be made from within the COmanage CO. The Platform menu is de= precated.
See also: Special Characteristics of the COmanage CO
In general, data should reside within a single CO, and data should be op=
aque (ie: not visible) to other COs. This is generally accomplished by havi=
ng a foreign key to some sort of parent record such as CoPerson or Co, and =
using standard authorization logic in isAuthorized()
. For data=
models with indirect relations to these parent keys, it may be necessary t=
o override functions like AppModel::findCoForRecord()
and
Previously, an exception to this model applied to Org Identities, howeve= r this capability is no longer available. See Organizational Identity Pooling.
As of Registry v3.3.3, foreign keys are by default frozen when a record =
is initially saved. That is, if a record has a foreign key to co_pers=
on_id
, once the record is created it can't be reassigned to a new CO=
Person. Freezing foreign keys prevents records from being moved across COs=
, in particular via the REST API (since the UI typically doesn't expose thi=
s capability).
In general, this is the correct default behavior, and should not be chan= ged. However, there are some foreign keys that should be unfrozen. For exam= ple, if a model has an option pointing to a CO Group (say, to configure who= is allowed to use the plugin), this foreign key might change from time to = time (say, to point to a new group). In general, foreign keys that show up = in the UI (probably as a SELECT) should probably be unfrozen.
Foreign keys can be unfrozen by updating the content
valida=
tion rule for the relevant attribute. Two settings are currently supported:=
CO
: The new value for the foreign key must point to a reco=
rd that is in the same CO. This is typically the correct setting.
yes
: Any value is permitted. This should only be used if t=
he foreign key controls a cross-tenant configuration, or if the attribute n=
ame for some reason looks like a foreign key, but actually isn't. If the attribut=
e name does not directly inflect to the parent model (eg: co_group_id=
to CoGroup
), make sure the association rule is correct=
ly defined in $belongsTo
.
public $= belongsTo =3D array( 'MembershipCoGroup' =3D> array( 'className' =3D> 'CoGroup', 'foreignKey' =3D> 'membership_co_group_id' ) ); public $validate =3D array( 'membership_co_group_id' =3D> array( 'content' =3D> array( 'rule' =3D> 'numeric', 'unfreeze' =3D> 'CO' ) ) );
As of Registry v5, foreign key freezing is based on the primary link for= the table.