The fix report

In Openbravo we have a great tool for Openbravo ERP and Openbravo POS, the Openbravo Issue Tracking System. This tool is open to all partners and members of the community. Here you can log new issues, search for open issues, closed issues, monitor the evolution of issues, participate in the issues discussions, etc. Issue reporting is very important. A good issue report is great for Openbravo engineers because it helps to evaluate the issue, and makes it easier to keep track of open issues, verify and fix them. In our wiki we have a defined QA Assurance Process and a detailed Bug Reporting Guidelines that explains how to log a good issue report. I recommend to everybody that works with Openbravo ERP and POS to have a look at these documents.

But if the issue report is very important to understand and fix the issue. The fix report is also very important too. The fix report is no more than a note added to the issue report by the engineer that explains in detail what has been done to fix the issue. The fix report makes it easier for the QA team to verify the correctness of a fix because when closing an issue they have to check that the issue is properly fixed and the modifications in the sources are correct. And it is important too for users, implementers and administrators of Openbravo ERP when they have to apply a fix or upgrade a live implementation. Changes in live Openbravo ERP environments are critical and we must provide to administrators the maximum confidence in the fixes provided. Apart from fixing the issue, the rest of the existing standard or custom functionality must continue working the same way. Usually regression issues introduced by an upgrade or a fix are several times worse than the issues fixed.

In order to improve the fix report we are introducing in the Support Team new guidelines to follow after a fix has been done and pushed to the Openbravo ERP or POS sources repository. The sections that this fix report must include are the following:

• Testing of the issue: Describes the steps to follow in Openbravo ERP or POS to verify that the issue has been fixed and the results obtained. It is usually very similar to the steps to reproduce but changing the results obtained.
• Explanation of the changeset that fixes the issue: High level explanation of the modifications in the sources. It should explain what has been modified in each file and why. For example when adding two new fields to a report, it has to be explained that the SQL query of the report has been modified to get the field values, the jasper report template has been modified to display the fields and also that has been included two new records in the AD_TEXTINTERFACES table to translate the report labels.
• Other areas affected by the changeset: Usually the changes done to fix an issue affects source code that is used in several parts of the application. In this section it has to be listed all the functional areas related with the change done and how are affected, and what are the changes in the behaviour if any. This section is very important because it helps to explore if any regression can appear with this fix. For example, when modifying the PL/SQL function C_INVOICE_POST, it has to be explained that all functions and windows that create and post invoices can be affected. It also has to be explained what are the type of invoices that can be affected by the issue, whether the invoices affected by this fix depends on the document type of the invoice or the payment terms...
  

You have a few examples of fix reports in the following issues: 12959, 12474, 12628 and 12856. And if you have suggestions to improve more the fix report we are currently implementing, we will be glad to hear them.