Regulations development in a master version for forms and processes: simplified modeling and overwrite protection

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. General description

In the process of developing or correcting minor errors that do not require significant changes in the regulations, the developer still has to do a large number of actions, namely — create a candidate version in the Admin portal, make changes to the regulations and integrate changes into the master version. It consumes a lot of time and effort. To improve the modeling experience, it is necessary to provide an opportunity to introduce changes directly into the master version of regulations.

2. Functional scenarios

Editing a form directly in the master version of the registry regulations.
Editing a business process directly in the master version of the registry regulations.
Creating a form directly in the master version of the registry regulations.
Creating a business process directly in the master version of the registry regulations.
Editing a form in the master version of the registry regulations with a simplified process of creating a candidate version.
Editing a business process in the master version of the registry regulations with a simplified process of creating a candidate version.
Creating a form in the master version of the registry regulations with a simplified process of creating a candidate version.
Creation a business process in the master version of the registry regulations with a simplified process of creating a candidate version.
Copying a form to the master version of the registry regulations.
Copying a business process to the master version of the registry regulations.
Deleting a form from the master version of the registry regulations.
Deleting a business process from the master version of the registry regulations.

All the functional scenarios refer to the Regulations modeling web interface.

3. User roles

Registry regulations developer

4. General provisions

The regulations developer can edit, create or delete a form or business process directly in the master version of the registry regulations.
Entity is the general name of a form or business process in this document.
The simplified process of creating a candidate version includes an automated sequence of steps after clicking the edit/create/delete entity button, namely entering information about the candidate version, creating a candidate version, making changes to the entity and saving changes to a candidate version.
When editing, creating and deleting an entity, it is necessary to ensure protection against overwriting the changes that may be made by other modelers.
When creating an entity, a verification for existence of an entity having the same name must be performed.
When editing and deleting an entity, a verification must be performed to ensure that the changes are applied in relation to the latest version of the entity (regardless of the candidate or master version).
When checking for availability of changes, it has to be taken into account that changes can be made both in the Admin portal and directly in Gerrit.
When editing and deleting an entity (http method PUT, DELETE), the general RestAPI Optimistic locking approach has to be used that is used in the system.
If conflicting changes are available, the system must remain in a consistent state after processing such a request.
If conflicting changes are available, a user must manually copy the edited content, refresh the entity page and make changes manually.
When making changes directly to master, a Gerrit MR must be created together with the submit and private parameters. Submit indicates that the changes must be integrated immediately. Private is used for separation to mark changes that do not require for running the pipeline to check the regulations (additional setting in the Jenkins-Gerrit integration).

5. Solution high-level design

Figure 1. Component diagram

Figure 2. Action chart. Creating an entity

Figure 3. Action chart. Updating an entity

Figure 4. Action chart. Deleting an entity

Overwrite protection

Figure 5. Creating a form/business process. Protection against changes overwriting

Figure 6. Updating a form/business process. Protection against changes overwriting

Figure 7. Deleting a form/business process. Protection against changes overwriting

6. Scope of work

6.1. Preliminary decomposition

[FE] Add the ability to create/edit a form/business process in the master version.
[BE] Extend the API for working with forms and business processes in the master version.
[DEVOPS] Configure the regulations checks pipeline to work only with the public Gerrit changes (exclude Private changes).
[FE] Add a simplified process for creating a candidate version from the entity creation page.
[FE] Add a link to Jenkins to track the regulations publication result in the Admin Portal.
[FE] Add user action prompts in handling of errors containing conflicts.
[BE] Implement BusinessProcessEtagInterceptor to check etag when updating a business process.
[BE] Add a check for duplicate names when creating an entity at the VersionedFileRepository level.
[BE] Add the etag check when updating an entity at the VersionedFileRepository level.
[BE] Add handling of merge conflicts when publishing changes to Gerrit.
[BE] Extend HeadFileRepositoryImpl with support for writing files to the repository.
[BE] Extend HeadFileRepositoryImpl with support for deleting files in the repository.
[FE] Add the ability to copy entity in the master version.
[FE] Add the ability to delete entity in the master version.
[DEVOPS] Add account service rights to RRM to perform the update by submit operation in Gerrit.

6.2. Changes to the REST API

Registry Regulation Management

6.3. Solution restrictions

In case of conflicting changes, a user needs to manually copy the content, refresh the page and repeat saving and conflict analysis.
The current design does not cover the actual deletion of forms and business processes in Form-management-provider and BPMS respectively.