Page History

...

Some additional conventions are required when writing a Dashboard Widget Plugin.

1. The name of the Plugin should match the format FooVetter.
2. The Plugin must implement a FooVetters model and a corresponding Controller.
   1. The Controller should extend StandardPluginController, which provides some behind the scenes common functionality.
   2. When a new Vetting Step is instantiated, a skeletal row in the corresponding foo_vetters table will be created. There is no add operation or view required. The skeletal row will point to the parent Vetting Step.
   3. The entry point to the Vetter Plugin configuration will be foo_vetter/foo_
wetters
3. 1. vetters/edit/#. This will be called immediately after the Plugin is first instantiated.
4. The table cm_foo_vetters should include a foreign key to cm_vetting_steps:id.
5. The plugin must implement FooVetter::vet($vettingStepId, $coPersonId, $coPetitionId=null), which will be called to perform the vetting. This function will be called from Registry Job Shell (via VetJob), and so should be able to operate without user interaction.
   1. This function should return an array with three elements:
      1. result: A VettingStatusEnum. See Vetting Results, below.
      2. comment: A human readable comment describing the results.
      3. raw: A text blob representing the actual vetting response generated/received, if appropriate. For example, this might be the full JSON returned from a remote API.
6. The plugin should implement a view for review, ie foo_vetter/foo_vetters/review/#. This view should parse the Vetting Result (available in $vv_result) and render a display suitable for an administrator to understand the request status. The Vetting Step configuration will be available in $foo_vetter. (The controller function is implemented in StandardPluginController, only the view file itself is required.)

Vetting Data Elements

It is up to the Plugin to determine which elements of the CO Person record to use for vetting, and how to use them.

...