See also: Writing Registry 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.
FooProvisioner
.CoFooProvisionerTarget
, and a corresponding Controller. (These are in addition to the other models and controllers required for Plugins.)CoProvisionerPluginTarget
.SPTController
("Standard Provisioning Target" Controller), which provides some functionality common to most/all Provisioners (including parsing of co_provisioning_target_id
).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.foo_provisioner/co_foo_provisioner_targets/edit/#/co:x
. This will be called immediately after the parent Provisioning Target is created.CoProvisioningTarget
has a hasOne
(ie: 1 to 1) relationship with CoFooProvisionerTarget
.co_foo_provisioner_target
should include a foreign key to co_provisioning_target:id
.co_foo_provisioner_target:id
.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 default status()
call.provision()
to execute provisioning for a CO Person, CO Group, CO Email List, or CO Service.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. Note that cascading delete, described above, will clean up any relevant tables. |
When a CO Group is provisioned, full group membership information is not provided with the provisioner, as groups can have sufficiently large numbers of members as to cause scalability issues. Instead, plugins requiring full group membership information should use the Group operations related to a single CO Person (eg: adding a CO Person to a CO Group) will include the relevant CO Person information in the provisioning data passed to the plugin. |
As of Registry v3.1.0, Identifiers may be associated with Provisioner Targets. This is useful if the plugin assigns or manages identifiers (for example, tracking the subject's identifier in the downstream system). Set |
As of Registry v4.0.0, ProvisionerBehavior properly enforces data filtering based on status as documented. "No data provisioned" means that the provisioners may be invoked (depending on context), but will only be provided a CO Person ID and status. This minimal information is so that provisioners can deprovision an existing record that has been downgraded, if appropriate. |