...
- Create a Model whose name matches the name of the Plugin. In this example, the Model is created at
app/Plugin/MyPlugin/Model/MyPlugin.php
.Define
$cmPluginType
to indicate the type of the Plugin, from the following options:$cmPluginType
Description
enroller
Enrollment Flow Plugin normalizer
Normalization Plugin
orgidsource
Organizational Identity Sources Plugin provisioner
Provisioning Plugin
other
Any other type of Plugin
Here's an example Model:
Code Block |
---|
class LdapProvisioner extends AppModel { // Required by COmanage Plugins public $cmPluginType = "provisioner"; } |
...
Plugin Types not listed here have no additional requirements.
...
The name of the Plugin should match the format FooEnroller
.
The entry point for Enrollment Flow Plugins is foo_enroller/foo_enroller_co_petitions/start/coef:#
for the start
step, and foo_enroller/foo_enroller_co_petitions/step/#
for all other steps (where # is the relevant CO Petition ID).
The easiest way to implement the Plugin itself is to extend CoPetitionsController
. This way, most of the overhead of processing the request will be handled for you, and your plugin need only implement execute_plugin_step
for each step you wish to process. (Note the name of each step is camelCased.) Once your plugin is finished, it should return control to the flow by redirecting back to the main flow, using the URL passed in $onFinish
. The redirect URL is also available in the view variable $vv_on_finish_url
.
Code Block | ||||
---|---|---|---|---|
| ||||
// Plugin/FooEnroller/Controller/FooEnrollerCoPetitionsController.php
App::uses('CoPetitionsController', 'Controller');
class FooEnrollerCoPetitionsController extends CoPetitionsController {
// Class name, used by Cake
public $name = "FooEnrollerCoPetitions";
public $uses = array("CoPetition");
/**
* Plugin functionality following petitionerAttributes step
*
* @param Integer $id CO Petition ID
* @param Array $onFinish URL, in Cake format
*/
protected function execute_plugin_petitionerAttributes($id, $onFinish) {
// Do some work here, then redirect when finished.
$this->redirect($onFinish);
}
}
|
Standard MVC rules apply. Note the corresponding Views will match the action name (eg: petitioner_attributes.ctp
) and not the function name.
Normalization Plugins
Some additional conventions are required when writing a Normalization Plugin.
- The name of the Plugin should match the format
FooNormalizer
. - The Plugin must implement one function, which is defined in
Model/FooNormalizer.php
.normalize()
, which accepts an array of data in typical Cake format and returns an array of normalized data in the same format. This function should be sure to copy any data to the return array that it does not modify, not just normalized data.
Provisioning Plugins
Some additional conventions are required when writing a Provisioning Plugin.
Provisioning Plugins are Provision*ers*, but the parent model is CoProvision*ing*. Be careful to reference the correct suffix.
- The name of the Plugin should match the format
FooProvisioner
. - The Plugin should implement a model
CoFooProvisionerTarget
, and a corresponding Controller. (These are in addition to the other models and controllers required for Plugins.)- This Model should extend
CoProvisionerPluginTarget
. - The Controller should to extend
SPTController
("Standard Provisioning Target" Controller), which provides some functionality common to most/all Provisioners (including parsing ofco_provisioning_target_id
). - When a new Provisioning Target is created, a skeletal row in the corresponding
co_foo_provisioner_targets
table will be created. There is noadd
operation or view required. The skeletal row will point to the parent Provisioning Target. - When a Provisioning Target is edited, the entry point to the Plugin will be
foo_provisioner/co_foo_provisioner_targets/edit/#/co:x
. This will be called immediately after the parent Provisioning Target is created.
- This Model should extend
- Note
CoProvisioningTarget
has ahasOne
(ie: 1 to 1) relationship withCoFooProvisionerTarget
. - The table
co_foo_provisioner_target
should include a foreign key toco_provisioning_target:id
.- Other tables used by the plugin should reference
co_foo_provisioner_target:id
.
- Other tables used by the plugin should reference
- The Plugin must implement two functions, which are defined in
Model/CoProvisionerPluginTarget.php
. See that file for the function signatures, including what data is passed to the Plugin and what results are expected to be returned.status()
to obtain the current provisioning status for a CO Person or CO Group. Note: there is a default implementation that may be sufficient for many provisioner plugins. Registry will automatically manage entries in cm_co_provisioning_exports and relay that information through the defaultstatus()
call.provision()
to execute provisioning for a CO Person or CO Group.
...
title | Provisioning and Delete Operations |
---|
When a delete operation passes through to a Provisioning Plugin, it will generally only be because a CoPerson (or CO Group) is deleted. (Deleting, say, a TelephoneNumber will show up as an update.) The plugin will be called before the delete has committed to the database. This is so that the underlying data is still available for the plugin to perform its work.
...