Audit trail more configurable.

[jhomarolo]

Is your feature request related to a problem? Please describe.
Today the herbs audit trail provided us with many inputs, but sometimes too much, especially when we are in a local environment (debug).

This has already generated some problems, such as writing bottlenecks, unnecessary information traffic, etc.

It would be nice to have the option of not displaying/generating a field in the audit trail.

[dalssoft]

The way I see it, these are the problems with the current implementation

• not configurable on the small details of the audit trail
• not able to disable the audit trail for a specific step
• doesn't handle big number of returned data
• doesn't handle sensitive data
• can be hard to read

With that, here are some ideas to improve the audit trail:

• make the audit trail configurable

const changeUserToAdmin = injection =>
    usecase('Change User to Admin', {

        auditTrail: {
            step: (step, auditTrail) => delete auditTrail.password, // function to be executed on each step
            usecase: (auditTrail) => delete auditTrail.return, // function to be executed on the end of the usecase
            auditUseCaseReturn: false, // if the audit trail should return the usecase return
            auditStepReturn: false, // if the audit trail should return the step return,
            auditElapsedTime: false, // if the audit trail should return the elapsed time
        },

        'Retrieve the User': step(async ctx => {

it could have multiple options, for each environment, for example:

config.auditTrail = isProd ? {
    auditStepReturn: false, 
} : {

}

const changeUserToAdmin = injection =>
    usecase('Change User to Admin', {

        auditTrail: config.auditTrail,

        'Retrieve the User': step(async ctx => {

• make audit trail easier to read

uc.auditTrail.format()

// would output a readable audit trail

• handle sensitive data

Audit Trail should, by default, not log sensitive data, like passwords, credit card numbers, etc. and have some convention to handle it.

This could be turned off by the user, but by default, it should be on.

[jhomarolo]

Does it make sense to put some global configuration for herbs? I don't know if the audit trail configuration should stay as a usecase parameter for an exception as the first choice.

What if I wanted all auditTrails to behave differently than the default?

About your auditTrail suggestions I think many are valid, but perhaps they should be treated more generally for now.

I believe that, for example, a functionality to handle sensitive data, could be discussed in another issue, because in my view this could be a configuration of the entity itself and the auditTrail just follows its configuration.

[dalssoft]

Does it make sense to put some global configuration for herbs?

It can be done, but as of now, we don't have a global configuration. There is a discussion about a global configuration file on the CLI, but it's not implemented yet.

As a workaround, a configuration file exporting a object with the configuration can be used, as shown in the example 2 (config.auditTrail).

What if I wanted all auditTrails to behave differently than the default?

Like different format / structure? I thought about it, but I'm more inclined to use just one structure for all audit trails in name of interoperability. If we have different formats, future consumers of the audit trail will lose the ability to consume a standard structure.

Since we have no consumers yet, we can change the structure now, but once it is defined, it will be the standard for all audit trails.

Another approach for what was presented is to have different audit trails levels, like auditTrail: 'full' or auditTrail: 'minimal', and the consumer can choose which level to consume.

I believe that, for example, a functionality to handle sensitive data, could be discussed in another issue, because in my view this could be a configuration of the entity itself and the auditTrail just follows its configuration.

Nice. I like the idea of having the sensitive metadata on the entity itself. After it is implemented, the audit trail must be aware of it.

[jhomarolo]

Fixed with #92