See also: Writing Registry Plugins
Some additional conventions are required when writing a Cluster Plugin.
- The name of the Plugin must match the format
FooCluster
. - The Plugin must implement a model
FooCluster
, and a corresponding Controller. (These are in addition to the other models and controllers required for Plugins.)- This Model should extend
ClusterInterface
, which defines some standard interfaces and provides some behind the scenes common functionality. - The Controller should extend
SCController
("Standard Cluster" Controller), which provides some common functionality. - When a new Cluster Backend is instantiated, a skeletal row in the corresponding
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. - When a Cluster Backend is edited, the entry point to the Cluster Plugin will be
foo_cluster/foo_clusters/edit/#
. This will be called immediately after the Cluster Backend is first instantiated.
- This Model should extend
- Note
Cluster
has a hasOne (ie: 1 to 1) relationship withFooCluster
. - The table
cm_foo_clusters
should include a foreign key tocm_clusters:id
.- Other tables used by the plugin should reference
cm_foo_clusters:id
.
- Other tables used by the plugin should reference
- The Plugin must implement an
assign()
function, the signature of which is defined inModel/ClusterInterface.php
. This function is called when automatic creation of an Account is created. - The Plugin must implement a
status()
function, the signature of which is defined inModel/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. - ProvisionerBehavior will use
$cmPluginHasMany
(inModel/FooCluster.php
) to determine which associated models to retrieve data for, in order to pass to Provisioning Plugins.- Supported parent models are CoGroup and CoPerson. ie: In order to be provisioned, the associated model must have a foreign key
co_group_id
orco_person_id
. - Additionally, models associated with CoPerson must define the following fields:
status
: Only records with valuesStatusEnum::Active
orStatusEnum::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 provisioned
- For example, in the following configuration FooClusterAccounts will be available to Plugins:
public $cmPluginHasMany = array("CoPerson" => array("FooClusterAccount"));
- Supported parent models are CoGroup and CoPerson. ie: In order to be provisioned, the associated model must have a foreign key
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.