What’s New?
These release notes outline what has changed in the latest release on 24 March 2021.
Improved Feature
Maintain Company Directors
This service allows changes to the Director details of a Company to be made. Existing Director’s details can be updated, existing Directors can be ceased and new Directors can be appointed.
Additional features include:
- Lookup of a person from another register (for example the Professional register)
- Re-use of another person already playing a role for that Company
- Re-use of any addresses associated with the Company or the logged-in user’s profile
- Alternate workflow if the changes made require a review by Registry staff
- Confirmation emails sent to the applicant
Read more about maintaining company Directors here.
Enhancements
- Display of pending and historical addresses and names
- IPAddress domain has been pulled up
- Updates to permission pools
- Updates in SPA to enforce security of all features
- Add “default status” field into “permissions” in “permission pools”
- Change to behaviour of service-confirmation platform tag
1. Display of pending and historical addresses and names
What changed?
A new display option expandoDisplayOptions has been provided in the SingleHistoricRepeater component. Note this is not the default. A value of columnindent makes the expando for historical/pending names/addresses appear in line with the values as opposed to the labels. The label(s) for the expandos has been changed as well.
Why?
To improve clarity and consistency of the data displayed on screen
Associated upgrade actions required
If the new indented expando is expected then the expandoDisplayOptions parameter needs to be passed with columnindent when using SingleHistoricRepeater component.
2. IPAddress domain has been pulled up
What changed?
- IPAddress domain has been pulled up into PresenterInstance instead of the corresponding Presenter domain.
- PresenterSection component was overridden, it has now been removed and the defaults of NZ are being set in the PresenterSection component of registry-quick-start
Why?
IPAddress is user dependent, and hence does not belong to the various type(s) of Presenter domains, and hence has been moved up.
Associated upgrade actions required
Any seeds, or data setup will need to be changed. There will be an update script provided.
3. Updates to permission pools
What changed?
- Labels (keys and values defined in
BaseConfiguration.groovyare updated. - Permission to manage SPA permission pools is changed from “managing permissions permission” to “managing pools permission”
- “checkChanges” dialog in the “MasterView.js” is replaced with “save-confirm-dialog” component
- “remove” labels in SPA are updated to be consistent
Why?
To improve consistency, mainly in permission pools functions
Associated upgrade actions required
- Update
Configuration.groovyaccordingly if any of the updated label is overriden in the class. And check the updated labels are aligned to the spec. - Update overridden SPA components accordingly
4. Updates in SPA to enforce security of all features
What changed?
SPA components have been updated to enforce security checking
Associated upgrade actions required
Update the overridden SPA components accordingly to apply new enforced securities.
5. Add “default status” field into “permissions” in “permission pools”
What changed?
- Data structure of “permissions” in “permission pools” is changed to have the new field “status”.
- “PermissionPoolSummary” class is updated to include status for the inside permissions. The places using this class are updated: “StandardRepositorySecurityService” class, “CookieSessionContextInitialiser” class and SPA groovy scripts.
- Permission pools seeding file format is changed from CSV to JSON to support having “default status” for each of the permissions in the permission pool.
- SPA permission pools related components are updated to support the new field “default status”
Why?
"Default status" is used in Organisations.
Associated upgrade actions required
- Update “security_permission_pools” table structure in database to support new field “status” for permissions.
- Update permission pools seeding files from CSV format to JSON format and add “status” field for the permissions.
- Update places using class “PermissionPoolSummary” to support status for permissions.
- Update SPA permission pools related components accordingly
- There will be an update script provided.
New data structure in DB:

New seeding file example:{"code": "PP01","permissions": {"PERM_COP502_GENERATE_EXTRACT_CERTIFICATE_COMPANY": "inherited","PERM_RNP501_VIEW_DETAILS_NAME_RESERVATION": "inherited","PERM_PRP001_ACCESS_PUBLIC_DATA_PROFESSIONAL": "inherited","PERM_PRP404_GENERATE_EXTRACT_CERTIFICATE_PROFESSIONAL": "inherited","PERM_COP001_ACCESS_PUBLIC_DATA_COMPANY": "inherited","PERM_PRP701_PROFESSIONALS_PUBLIC_SEARCH": "inherited","PERM_COP701_COMPANIES_PUBLIC_SEARCH": "inherited","PERM_P110_VIEW_ENTITY_FILINGS_HISTORY": "inherited","PERM_COP500_VIEW_DETAILS_COMPANY": "inherited","PERM_P230_CREATE_MY_EXTERNAL_USER_PROFILE": "inherited","PERM_PRP500_VIEW_DETAILS_PROFESSIONAL": "inherited","PERM_P229_ACTIVATE_MY_INTERNAL_USER_PROFILE": "inherited","PERM_P227_GUEST_USER_LANDING_PAGE": "inherited"},"name": "Guest user","desc": "Guest user inherits all permissions listed in this pool as well as access associated with permission SP001 Guest user"}
6. Change to behaviour of service-confirmation platform tag
What changed?
Now supports "start-as-copy" attribute to control whether the confirmation service is is started as a copy of the submitted service or as a subsequent service. Default behaviour is different depending on whether a service code is provided. If a service code is included the default is to start the service as a new service. If only a form code is provided the default is to start the service as a copy of the submitted service. The start-as-copy attribute can be used to alter this behaviour.
Why?
Starting the service as a copy allows access to serviceTree data for the confirmation.
Associated upgrade actions required
Add start-as-copy attribute to any elements which do not want the default behaviour.
7. Change to relationship derivation
What changed?
Now supports precedence to allow relationships to be added in order and inspect existing relationships when decided whether to add a relationship
Why?
If the service initiator should have a Director relationship they should not also have an Agent relationship.
Associated upgrade actions required
Update relationship instructions to include precedence and rule to prevent agent relationship if required.
Example:<!-- Director relationship --><relationshipInstruction name="directorRelationship"relationshipName="Director"permissionPool="PP13"><!-- Relationship Instruction to create a Director Relationship linking the current (external) user to a Director on thisCompany --><relationshipScope service="privateCompanyRegister,privateCompanyMaintainDirectors"domain="Director"attributeDomain="Person"attribute="UserIdentifier"matchType="userNonBlank"><rule type="groovy"><![CDATA[return!(appCtx.userHasInternalPermission() && attributeDomainNode.getAttribute('UserIdentifier').asString() == appCtx.userIdentifier)]]></rule></relationshipScope></relationshipInstruction><!-- Agent relationship --><relationshipInstruction name="agentRelationshipViaRegister"relationshipName="Agent"permissionPool="PP14"skipForInternal="true"precedence="1"><!-- Relationship Instruction to create an Agent Relationship forthe current current (external) user to thisCompany --><relationshipScope service="privateCompanyRegister"matchType="initiator"><rule type="groovy"><![CDATA[results.stream().filter{it.scope.domain == "Director"&& it.userIdentifier == appCtx.userIdentifier}.map{false}.findFirst().orElse(true)]]></rule></relationshipScope></relationshipInstruction>
Fixes
- Presenter instance data structure
- Open API – attribute value is reset on read-only attribute when the node is visible
- Open API – Error level should be returned in the response
- InputCoercionException on Currency component
- Navigation to the error in error panel

