About Plugins
Installing Plugins
There are a few different ways to make Plugins available for use within Registry, according to how the Plugin is distributed.
- Core Plugins - Commonly used. These plugins ship with COmanage and enabled by default.
- Supported Non-core Plugins - Less widely used. Shipped with COmanage, but not enabled by default.
- External Plugins - Finally, Plugins can come from other sources (including those you write yourself) to support your needs.
Core Plugins
Many Plugins are already set up, and provided as “Core Plugins”; these Plugins ship with COmanage, and are enabled by default. They can be found in the app/Plugin directory.
Supported Non-core Plugins
In addition, there are some Plugins that are less widely used. While they are shipped with COmanage, they are not enabled by default because of the related overhead (and, in some cases, external dependencies) associated with Plugins that may only be useful to some deployments. These plugins are also shipped with Registry and can be found in the app/AvailablePlugin directory.
The simplest way to enable a Non-Core Plugin (assuming you have met any external dependencies the Plugin may require) is to symlink it from your local/Plugin directory.
After creating the symlink, you should clear caches and then update your database schema to reflect the newly available plugin.
| Code Block |
|---|
| language | bash |
|---|
| theme | RDark |
|---|
| title | Enabling a Non-core Plugin |
|---|
|
$ cd $REGISTRY/local/Plugin
$ ln -s ../../app/AvailablePlugin/SomePlugin .
$ cd $REGISTRY/app
$ su -c "./Console/clearcache" ${APACHE_USER}
$ su -c "./Console/cake database" ${APACHE_USER} |
External Plugins
Plugins that come from other sources (including those you write yourself) should be placed in the local/Plugin directory.
Configuring & Using Plugins
Once a Plugin is installed and enabled for use, how it is actually used and/or configured varies according to the Plugin type.
| Plugin Type | Description | Where the plugin is configured in COmanage |
|---|
| Authenticator | Authenticators are used to prove a CO Person's identity to an application or service. Because Authenticators are collaboration issued, they are attached to the CO Person, not to Organizational Identities (as for external credentials). |
|
| Cluster | Clusters are used to represent a CO Person's accounts within a given application or service. The typical use case is managing accounts on (eg) one or more Unix servers, but there is no specific requirement for this type of service. |
|
| Dashboard Widget | Registry v3.2.0 introduces Dashboards, simple information portals. Information is provided by Dashboard Widgets, which are implemented as Dashboard Widget Plugins. Multiple Dashboards can be defined within a CO. Dashboards include header and footer text areas appropriate for providing arbitrary html content on the landing page of a CO. |
|
| Data Filter |
|
|
| Enrollment Flow |
|
|
| Identifier Validation |
|
|
| Invitation Confirmer |
|
|
| Job |
|
|
| LDAP Schema |
|
|
| Normalization |
|
|
| Organizational Identity Source |
|
|
| Provisioner |
|
|
Creating Your Own Plugins
Building your own plugin is a great was to get started with custom development for COmanage. Through plugins you can build powerful extensions to the existing Registry functionality. Building a Registry Plugin requires knowledge of PHP, CakePHP, and COmanage.
Start Here
The general documentation for building plugins can be found on the Writing Registry Plugins page. All plugins follow some standard conventions which are outlined on this page. In addition, some types have additional requirements as listed below.
Additional Requirements by Plugin Type
As described above, there are several different Plugin Types, each with their own additional requirements. You can find these details at the links below: