You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Manual Schema Update May Be Required

Some columns have been resized. Due to a bug in the underlying schema management library, this resize may not automatically happen on Postgres. If necessary, manually resize the columns.

sql=> alter table cm_ssh_keys alter column type type varchar(32);
sql=> alter table cm_co_jobs alter column job_type type varchar(32);

Enrollment Flow Steps "Deny" and "Send Approval Notification" Removed

Registry v3.3.0 consolidates three Enrollment Flow Steps into the Approve step, eliminating the Deny and Send Approval Notification steps. Custom plugins that execute after Deny or Send Approval Notification should be updated to execute after Approve instead.

SSH Key Authenticator Plugin

SSH Key management has moved into an Authenticator Plugin. During the upgrade to v3.3.0, any CO that has SSH Keys attached to a CO Person will have an SSH Key Authenticator automatically instantiated, and existing keys will be attached to that Authenticator. COs that do not have any SSH Keys will need to instantiate an Authenticator before SSH keys can be managed.

SSH Keys are no longer managed directly from the CO Person Canvas, but are now available via the Authenticators link in the sidebar.

Authenticator Plugin Documentation

The guidance for when Authenticator Plugins should trigger provisioning has been corrected.

JobShell and Job Plugins

Registry v3.3.0 introduces Job Plugins, as executed by the Registry Job Shell. All existing deployments will likely need to update their cron configuration, as described in Registry Installation - Cron.

API User Changes

As of Registry v3.3.0, API Users are assigned to specific COs. Full information is available in the documentation, however the following changes should be noted:

  • New API Users must be named with their CO as a prefix.
  • Self selected passwords are no longer supported, instead randomly generated API Keys are used.
  • Platform API Users are now created via the COmanage CO.

Existing API Users (those created prior to upgrade) will continue to function as is, and will be automatically assigned to the COmanage CO as Platform API Users (without being renamed). However any subsequent changes to existing API Users will require conformance with the new naming and API Key requirements. It is recommended that existing APU Users be manually transitioned at a convenient time.

  • No labels