Implementing Maker/Checker for all entities

Hi,

I work in financial domain and hence the requirement. Although I have not explored the complete CUBA paltform yet, but just curious to know if Cuba Platform supports out of the box functionality for implementing Maker/Checker for entities.

To elaborate more on Maker/Checker - It’s basically a functionality expected in almost all the entities that whenever a CRUD operation is performed on the Entity, it should not persist the changes like Insert new record/update or delete but rather store in some intermediary table or same table with a status of Unauthorised state. Once the changes have been authorized by another user of the system, it should persist in final table or update the status as Authorised. Also, to add more, a maker of an entity can’t be checker. Like one user who creates a record by creating an entity instance should not be allowed to authorised the creation. It has to be a different user.

More information can be found on search engine with terminologies such as Maker/Checker and 4 Eye principle.

My issue is if I start to implement this functionality for like 50 to 100 of entities in my project which I’m planning to implement in Cuba platform it will impact the development timeliness more than business logic. So wanted to hear from the experts and Cuba platform users their views around it such as suggestion to reduce this effort by having some global configuration in the platform or design approach to be followed before starting with the project.

Hi
If you haven’t taken a loot at BPM in CUBA Framework, please check it out, that may serve your purpose.

Hi Mortoza,

I have worked on several BPM products extensively but its doesn’t fit well for custom applications. Or you could throw some lights on it how could we model a bpm process around entities in Cuba as i beleive it needs to be created and executed on bpm engine.
Let say we have 10 business entities in a simple application for Branch managememt, simple CRUD operations being performed like create a branch by accepting data from user and have to be kept in unauthorized state, how does bpm fit in this? I dont have choice to go for pure bpm based workflow, i need to develop a custom solution like normal web based application. Do you have any sample for using bpm engine for cuba in cuba applications?

Hi Shoaib,

Currently, CUBA has no out-of-the-box implementation of the Maker-checker principle. But I think you could implement it either using BPM or programmatically.

BPM in CUBA is tightly integrated into the application and can be easily linked to entities for managing their state. You can take a look at the Quick Start section of the BPM documentation to get a sense of it.

Perhaps using BPM would be an overkill for a simple project or if you don’t need to manage your entities beyond “Unauthorised/Authorised” state transition. So you can prepare some base infrastructure in your project and use it for entities that require authorization.

First, create a MappedSuperclass with the authorized attribute. Inherit entities from it.

Then create an entity listener implementing the BeforeUpdateEntityListener interface and add it to your MappedSuperclass. So all inherited entities will trigger it before saving to the database. In the listener, you can easily check the following:

  • What state the entity is now (your authorised attribute)
  • Who created the entity (createdBy attribute)
  • Who is the current user (UserSessionSource.getUserSession().getUser())
  • Whether the current user has the right to authorize. I think a suitable tool for this would be CUBA specific permissions - you call Security.isSpecificPermitted(“myapp.authorisationEnabled”) in the entity listener, and assign this permission to some user role at runtime. Then all users belonging to this role will be able to authorize.

You can also use CUBA row-level security (Access Group > Constraints) to restrict access to unauthorized records for some categories of users. Or even implement all above logic in a constraint - see the documentation for details.

2 Likes