Hi all,
OFBiz has an EntityAuditLog entity log system, which allows all changes to be recorded in a specific field of a table. This allows you to have a technical follow-up on what is recorded in a field. Following monitoring needs on a production environment at a customer's site, we have identified two limitations to the current implementation. First, unlike logs that can be modified in production, it is not possible to modify the audit values of entities in production. It is therefore not possible to take advantage of the information provided by this entity to help detect production problems. To do this, it would be necessary to be able to activate and deactivate the audit of a field without having to redeploy or restart OFBiz. Currently the activation is done in the entity definition. The objective would be to be able to define it at another level in order to be able to modify the value dynamically. Second, the entityauditlog entity is used to store functional data. We believe that this is a mistake and that the use of this entity must be purely technical. For this reason we propose to modify the current code in order to remove the use of the entity audit entity log in a functional way. What do you think of that? Thanks Pierre GAUDIN |
Hi Pierre,
On 07/10/2019 10:15, pierre.gaudin wrote: > Hi all, > > OFBiz has an EntityAuditLog entity log system, which allows all > changes to be recorded in a specific field of a table. This allows you > to have a technical follow-up on what is recorded in a field. > Following monitoring needs on a production environment at a customer's > site, we have identified two limitations to the current implementation. > > First, unlike logs that can be modified in production, it is not > possible to modify the audit values of entities in production. It is > therefore not possible to take advantage of the information provided > by this entity to help detect production problems. To do this, it > would be necessary to be able to activate and deactivate the audit of > a field without having to redeploy or restart OFBiz. Currently the > activation is done in the entity definition. The objective would be to > be able to define it at another level in order to be able to modify > the value dynamically. > > Second, the entityauditlog entity is used to store functional data. We > believe that this is a mistake and that the use of this entity must be > purely technical. For this reason we propose to modify the current > code in order to remove the use of the entity audit entity log in a > functional way. In my vision use entity audit log to detect some functional modification seems to be a bad hack to compensate bad functional design. So +1 to quick out all functional analyze that exploits entity audit log Nicolas > > What do you think of that? > > > Thanks > > > Pierre GAUDIN > > |
Administrator
|
Hi Pierre, Nicolas,
I totally agree: +1 Jacques Le 14/10/2019 à 09:41, Nicolas Malin a écrit : > Hi Pierre, > > On 07/10/2019 10:15, pierre.gaudin wrote: >> Hi all, >> >> OFBiz has an EntityAuditLog entity log system, which allows all changes to be recorded in a specific field of a table. This allows you to have a >> technical follow-up on what is recorded in a field. Following monitoring needs on a production environment at a customer's site, we have identified >> two limitations to the current implementation. >> >> First, unlike logs that can be modified in production, it is not possible to modify the audit values of entities in production. It is therefore not >> possible to take advantage of the information provided by this entity to help detect production problems. To do this, it would be necessary to be >> able to activate and deactivate the audit of a field without having to redeploy or restart OFBiz. Currently the activation is done in the entity >> definition. The objective would be to be able to define it at another level in order to be able to modify the value dynamically. > We can use the same pattern use on cache system to define it. >> >> Second, the entityauditlog entity is used to store functional data. We believe that this is a mistake and that the use of this entity must be >> purely technical. For this reason we propose to modify the current code in order to remove the use of the entity audit entity log in a functional way. > > In my vision use entity audit log to detect some functional modification seems to be a bad hack to compensate bad functional design. > > So +1 to quick out all functional analyze that exploits entity audit log > > Nicolas > >> >> What do you think of that? >> >> >> Thanks >> >> >> Pierre GAUDIN >> >> > |
Free forum by Nabble | Edit this page |