Projects:Full Audit Trail/Functional Documentation
Contents |
Overview
Currently Openbravo ERP has a poor support for audit trailing, allowing only to maintain the user and time that created each record and the user and time for the last modification of each record.
Purpose
The purpose of this project is to enhance audit trail support, to allow in Openbravo ERP to keep a complete history of tables and to support the creation of modules to do some extra auditing.
Scope
The scope for this project is.
- Data history. Allow core to maintain a complete history of record modifications.
- Query auditing support. Implement in core support for creation of modules that maintain history of queries performed on database.
- Query auditing module. Implementation of a module making use of these capabilities.
- Navigation auditing support. Implement in core support for logging in modules all the navigation actions performed by user.
- Navigation auditing module. Implementation of a module making use of these capabilities.
References
Design Considerations
Assumptions
Dependencies
Query auditing support and Navigation auditing support require the support for JMS which will require support for JNDI.
Constraints
Glossary
Functional Requirements
User roles & profiles
Business process definition
User stories
Functional requirements based on business processes
Data history
To support historical data log it is necessary to:
- Add a new check in table tab, this check will allow to optionally maintain the log.
- Add a process that creates the infrastructure for audited tables. This infrastructure will consists on:
- A copy of the original table.
- Triggers to be executed when the original table is modified, these trigger will populate the audit table.
- Application Dictionary mapping for these tables.
- UI visualization for this info.
- Manage properly this infrastructure by DBSM. As the audit infrastructure is calculated from the model, it shouldn't be exported when the rest of the database is exported.
Query Auditing Support
In order to allow this implementation it is needed that core supports JMS.
Query Auditing Support is divided in two sub items: Core and Module.
Core
The support in core for this feature includes:
- Each time a SQLC query is executed a JMS message is queued in a specific topic.
- Each time a DAL query is executed a JMS message is queued in a specific topic.
Module
The actual management for the data produced and queued in the JMS topic is done through modules.
A module to support this will be implemented, though different modules could implement it in different ways. This module will include:
- Infrastructure to persist this info.
- A JMS topic listener that saves the info.
In order to allow this implementation it is needed that core supports JMS.
Navigation auditing support is divided in two sub items: Core and Module.
Core
- HttpSecureServlet class queues a JMS message in a known topic each time a request to a Servlet is performed.
Module
- Infrastructure to persist this info.
- A JMS topic listener that saves the info.