Page History

...

1. The name of the Plugin should match the format FooProvisioner.
2. The Plugin should implement a model CoFooProvisionerTarget, and a corresponding Controller. (These are in addition to the other models and controllers required for Plugins.)
   1. This Model should extend CoProvisionerPluginTarget.
   2. The Controller should to extend SPTController ("Standard Provisioning Target" Controller), which provides some functionality common to most/all Provisioners (including parsing of co_provisioning_target_id).
   3. When a new Provisioning Target is created, a skeletal row in the corresponding co_foo_provisioner_targets table will be created. There is no add operation or view required. The skeletal row will point to the parent Provisioning Target.
   4. 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.
3. Note CoProvisioningTarget has a hasOne (ie: 1 to 1) relationship with CoFooProvisionerTarget.
4. The table co_foo_provisioner_target should include a foreign key to co_provisioning_target:id.
   1. Other tables used by the plugin should reference co_foo_provisioner_target:id.
5. 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.
   1. 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 default status() call.
   2. provision() to execute provisioning for a CO Person or CO Group.

...