See also: Writing Registry Plugins
Some additional conventions are required when writing a Cluster Plugin.
FooCluster
.FooCluster
, and a corresponding Controller. (These are in addition to the other models and controllers required for Plugins.)ClusterInterface
, which defines some standard interfaces and provides some behind the scenes common functionality.SCController
("Standard Cluster" Controller), which provides some common functionality.co_foo_clusters
table will be created. There is no add operation or view required. The skeletal row will point to the parent Cluster Model.foo_cluster/foo_clusters/edit/#
. This will be called immediately after the Cluster Backend is first instantiated.Cluster
has a hasOne (ie: 1 to 1) relationship with FooCluster
.cm_foo_clusters
should include a foreign key to cm_clusters:id
.cm_foo_clusters:id
.assign()
function, the signature of which is defined in Model/ClusterInterface.php
. This function is called when automatic creation of an Account is created.status()
function, the signature of which is defined in Model/ClusterInterface.php
. This function returns an array, which currently holds one element: comment
, a human readable description of the Cluster status for the specified CO Person.$cmPluginHasMany
(in Model/FooCluster.php
) to determine which associated models to retrieve data for, in order to pass to Provisioning Plugins.co_group_id
or co_person_id
.status
: Only records with values StatusEnum::Active
or StatusEnum::GracePeriod
are provisioned.valid_from
: Records with values prior to "now", or a NULL value, are provisionedvalid_through
: Records with values later than "now", or a NULL value, are provisionedpublic $cmPluginHasMany = array("CoPerson" => array("FooClusterAccount"));
Note that, unlike Authenticator Plugins, there is currently no Registry-provided management functionality ("lock", "unlock", etc). Cluster Plugins must (currently) provide this functionality on their own.