Log in / create account
Openbravo.com
Issues
Forge
University
View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

Openbravo Localization Quality Assurance CheckList

Contents

Introduction

This document lists the mandatory and non-mandatory checks to verify for validating the quality of an Openbravo Localization Pack.

Mandatory and non-mandatory checks are split into two, therefore both the "Community" and the "Professional" edition of an Openbravo Localization can be validated.

It is important to remark that Localization projects ready to be published can be published in "QA Approved" status only if all the mandatory checks included on the validation list are successfully passed.

The Professional Localizer is required to ensure the quality of a localization pack, therefore before asking Openbravo to validate the quality of a localization pack needs to be sure that the mandatory checks
have been successfully validated.

Mandatory checks

All the checks included in this section must be mandatory passed.
In case just one is not passed, the localization pack must be rejected. The "localization" owner should fix the issue7s before another Openbravo's validation.

Community Edition

Check 1 - Community Pack Content

The "Community" pack must contain at least:

all of them under an "Openbravo Public License" (OPL)

Other modules can be included into the "Community" pack referring to basic localization areas such as:

Finally, a Community Localization pack is not intended to include "Templates" that modify the core application.
For additional information on this regard please review this article.

Check 2 - Community Pack Documentation

Openbravo can validate and monitor localization documentation depending on the local language used, otherwise Openbravo could request a report or any documentation written in English.

The "Community" pack of an Openbravo Localization must be properly documented.

Above means that there should be an "Openbravo" wiki page, tagged as Category:India for instance, linked to the corresponding "Community Pack" project published in the Forge that includes:

See an example below:

Community Localization India in English.

Community Localization Mexico in Spanish.

Bulbgraph.png  

Disclaimer

Please note that above ones are "real" Community Localization examples, therefore do not change those wiki pages but create new ones for your localization.

For instance, if you want to document the Community Localization of France, create the wiki page: http://wiki.openbravo.com/wiki/Community_Localization_France

Above described documentation can be written on the "local" language.

Check 3 - Community Modules Documentation

Each module/feature contained in a "Community" pack needs to be properly documented.

Above means that there should be an "Openbravo" wiki page tagged same way as described above and linked to the corresponding project published in the forge, which includes:

See an example below:

Chart of Accounts India

Cuentas Contables Mexico

Bulbgraph.png  

Disclaimer

Please note that above ones are "real" Community features documentation examples, therefore do not change those wiki pages but create new ones for your localization.

For instance, if you want to document the Chart of Accounts module for France, create the wiki page http://wiki.openbravo.com/wiki/Chart_of_Accounts_France

Above described documentation can be written on the "local" language.

Check 4 - Installation in PostgreSQL

  1. Can we install the community pack in PostgreSQL?
  2. Did we get any warning during the installation process?

Check 5 - Installation in Oracle

  1. Can we install the professional pack in Oracle?
  2. Did we get any warning during the installation process?

Check 6 - Community Dataset application

There can be datasets included in the "Community" pack. Dataset checks are related to:

  1. Have all the system level dataset (if any) been applied successfully?
  2. Have all the dataset available into the community pack been applied successfully (taking into account its dependencies and the level at which should be applied) as described in the corresponding installation guide?

Check 7 - Community Pack/Modules definition

All the modules/packs included in the community version of an Openbravo localization are properly defined.
Above means that all the modules/pack contained in a "Community" Pack must have:

It is also important to check that they have followed the Naming guidelines for modules. Specially verify that "Module Names" are written in English (even for non-English modules).

Above can be verified as "System Administrator" role, in the "Module" window.

Check 8 - Community Pack/Modules publication in the Forge

It is really important to check that the community pack and all the modules/packs included in it are published in the Openbravo Forge (or Openbravo Central Repository) as described below:

It is also important to check that all the projects related to the commercial modules/pack have:

If you have any question related to any "localization" project tools link please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).

Chart of Accounts checks

Chart of Accounts related checks are:

  1. Run the Initial Client Setup process for creating a new client with accounting and select the chart of accounts. Ensure that the client is successfully created.
  2. Run the Initial Organization Setup process for creating a new Legal with Accounting organization and select the chart of accounts. Ensure that the organization is successfully created.
    In case the pack includes more than one chart of accounts module, repeat the previous checks for all of them.
  3. Review the "Account Tree" to check that it follows a "Balance Sheet" and "Income Statement" structure.
  4. Review the "Account Tree" to check that there are not "Suspense" accounts located out of a specific node that is not the Balance Sheet or Income Statement node.
  5. Review the "General Ledger Configuration" so it is linked to the "Account Tree".
  6. Review the "General Ledger Configuration" so it properly has all the the mandatory "General Accounts" and mandatory "Defaults" accounts configured.

Translation Pack checks

Translation checks are related to:

  1. All the translation modules should be included into a translation pack. This translation pack should be included in the "Community" pack.
  2. Ensure that there is a translation module per each module inside the Openbravo 3 distribution. Currently there should be 13 translation modules for the modules: Query/List Widget, JSON Datasource, User Interface Application, Widget Collection, User Interface Client Kernel, Advanced Payables and Receivables, HTML Widget, Orders Awaiting Delivery, Smartclient, User Interface Selector, Workspace & Widgets, Payment Report and Core.
  3. Once installed, login into Openbravo and go to the change role popup. Ensure that the new language can be selected
  4. Change the User Interface to the new language and browse several windows, specially the most important ones, like Purchase/Sales Order, Goods Shipment, Good Receipt, Sales/Purchase Invoice, Business Partner and Product. Ensure that the application looks like it is properly translated.
  5. Take some percentages about the translation status. Ensure that the translated percentage is always greater than 75%.

You can use the following SQL queries to get an approximate percentage, replacing es_ES by the correspondent language:

AD_Message
select round((select count(*)
from ad_message m
join ad_message_trl mt using (ad_message_id)
where m.msgtext <> mt.msgtext
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_message), 2) ||'%' as Translated
from dual;

AD_TextInterfaces
select round((select count(*) from ad_textinterfaces m
join ad_textinterfaces_trl mt using (ad_textinterfaces_id)
where m.text <> mt.text
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_textinterfaces), 2) ||'%' as Translated
from dual;

AD_Element
select round((select count(*) from ad_element m
join ad_element_trl mt using (ad_element_id)
where m.name <> mt.name
or m.printname <> mt.printname
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_element), 2) ||'%' as Translated
from dual;

AD_Tab
select round((select count(*) from ad_tab m
join ad_tab_trl mt using (ad_tab_id)
where m.name <> mt.name
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_tab), 2)||'%' as Translated
from dual;

AD_Window
select round((select count(*) from ad_window m
join ad_window_trl mt using (ad_window_id)
where m.name <> mt.name
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_window), 2) ||'%' as Translated
from dual;

Taxes configuration checks

Taxes module related checks are:

  1. Go to the Tax Rate window and get the number of tax rates included into the module. Ensure that the number is great enough.
    1. Take a look at some tax rates and ensure that they are properly defined.
    2. Ensure that there are no summary level tax rates without any child. You can use the following SQL query.
      select t1.*
      from c_tax t1
      where t1.issummary='Y'
      and not exists (select 1
      from c_tax t2
      where t1.c_tax_id=t2.parent_tax_id)
    3. Verify the Tax Zone tab has several records. In case no records (or a few) are there, it may indicate a problem in the tax rate definition. You can use the following SQL query:
      select count(*)
      from C_Tax_Zone
      where ad_client_id=<clientID>
  2. Go to the Tax Category window and ensure that several records are created. In case just one record is there, it may indicate a low quality taxes module.
  3. Go to the Business Partner Tax Category window and ensure that several records are created. In case no records are there, it may indicate a low quality taxes module.

Professional Edition

Check 1 - Professional Pack Content

The "Professional" pack must contain at least:

Other modules can be included into the "Professional" pack referring to not that basic but more complex localization areas such as:

Finally, a Professional Localization pack is not intended to include "Templates" that modify the core application.
For additional information on this regard please review this article.

Check 2 - Professional Pack Documentation

Openbravo can validate and monitor localization documentation depending on the local language used, otherwise Openbravo could request a report or any documentation written in English.

The "Professional" pack of an Openbravo Localization must be properly documented.

Above means that there should be an "Openbravo" wiki page, tagged as Category:Mexico for instance, linked to the corresponding "Professional Pack" project published in the Forge that includes:

See an example below:

Professional Localization India in English.

Professional Localization Mexico in Spanish.

Bulbgraph.png  

Disclaimer

Please note that above ones are "real" Professional Localization examples, therefore do not change those wiki pages but create new ones for your localization.

For instance, if you want to document the professional localization for France, please create the wiki page: http://wiki.openbravo.com/wiki/Professional_Localization_France

Above described documentation can be written on the "local" language.

Check 3 - Professional Modules Documentation

Each module/feature contained in a "Professional" pack needs to be properly documented.

Above means that there should be an "Openbravo" wiki page tagged same way as described above and linked to the corresponding project published in the forge, which includes:

See an example below:

Service Tax India

Cálculo Impuestos México

Bulbgraph.png  

Disclaimer

Please note that above one is a "real" Community feature documentation example, therefore do not change that wiki page but create new ones for your localization.

For instance, if you want to document the most common methods of payment used in France, create the wiki page: http://wiki.openbravo.com/wiki/Methods_Of_Payment_France

Above described documentation can be written on the "local" language.

Check 4 - Installation in PostgreSQL

  1. Can we install the professional pack in PostgreSQL?
  2. Did we get any warning during the installation process?

Check 5 - Installation in Oracle

  1. Can we install the community pack in Oracle?
  2. Did we get any warning during the installation process?

Check 6 - Professional Dataset

There can be datasets included in the "Professional" pack. Dataset checks are related to:

  1. Have all the system level dataset (if any) been applied successfully?
  2. Have all the dataset available into the professional pack been applied successfully (taking into account its dependencies and the level at which should be applied) as described in the corresponding installation guide?

Check 7 - Professional Pack/Modules definition

All the modules/packs included in the professional version of an Openbravo localization must be properly defined.
Above means that all the modules/pack contained in a "Professional" Pack must have:

It is also important to check that they have followed the Naming guidelines for modules. Specially verify that "Module Names" are written in English (even for non-English modules).

Above can be verified as "System Administrator" role, in the "Module" window.

Check 8 - Professional Pack/Modules publication in the Forge

It is really important to check that the profesional pack and all the modules/packs included in it are published in the Openbravo Forge (or Openbravo Central Repository) as described below:

It is also important to check that all the projects related to the commercial modules/pack have:

If you have any question related to any "localization" project tools link please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).

Non Mandatory checks

Validating the quality of a localization pack is a difficult task, specially when we are checking modules with code that implements a concrete business logic.

However we can run a set of verifications that, at least, will give us a clue about the quality of the code.

In general this kind of tests should not reject the localization pack, but just give us a rough idea about its quality.

Community Edition

Functional Review

The documentation provided for the "Community" modules/packs as described in Check 3 above, needs to be clear enough to allow the end-users to easily understand, configure and use those modules/features.

Openbravo can do a functional review as the language of the documentation provided by the localizer is either in English or Spanish language.

Module structure

Take one by one all the modules contained in the community pack/s and examine the file contents.

  1. Ensure that there is a legal folder with the license text inside it in case it is necessary
  2. Ensure that the files inside the pack fulfill the Openbravo standards
  3. In case of including templates, ensure that they have sense.

Code review

Database structure

  1. Open some XML files that define new database tables and ensure that the mandatory columns have been declared (ad_client_id, ad_org_id, created...)
  2. Open all the XML files that define new external columns and ensure that the "oncreatedefault" is set for the not null columns

PL/SQL code

  1. Pay special attention to triggers. Do a quick code review, paying special attention to mutant table issues
  2. Review INSERT and DELETE clauses. Ensure they don't break end-user important data (business partners, products, invoices, orders, etc.)

Java code

  1. Ensure that no XSQL files are present. All the queries to the database must be done using DAL
  2. Do a quick review of some Java classes. Study the code structure, the cleanliness, the control over errors and exceptions, the use of log4j, etc.

Javascript code

  1. Try to run JSLint for the Javascript code and check for errors

Professional Edition

Functional Review

The documentation provided for the "Professional" modules/packs, mainly the user manuals provided as described in Check 3 above, needs to be clear enough to allow the end-users to easily understand, configure and use those modules/features.

Openbravo can do a functional review as the language of the user manuals provided by the localizer is either in English or Spanish language.

Module structure

Take one by one all the modules contained in the pack/s and examine the file contents.

  1. Ensure that there is a legal folder with the license text inside it in case it is necessary
  2. Ensure that the files inside the pack fulfill the Openbravo standards
  3. In case of including templates, ensure that they have sense.

Code review

Database structure

  1. Open some XML files that define new database tables and ensure that the mandatory columns have been declared (ad_client_id, ad_org_id, created...)
  2. Open all the XML files that define new external columns and ensure that the "oncreatedefault" is set for the not null columns

PL/SQL code

  1. Pay special attention to triggers. Do a quick code review, paying special attention to mutant table issues
  2. Review INSERT and DELETE clauses. Ensure they don't break end-user important data (business partners, products, invoices, orders, etc.)

Java code

  1. Ensure that no XSQL files are present. All the queries to the database must be done using DAL
  2. Do a quick review of some Java classes. Study the code structure, the cleanliness, the control over errors and exceptions, the use of log4j, etc.

Javascript code

  1. Try to run JSLint for the Javascript code and check for errors

Retrieved from "http://wiki.openbravo.com/wiki/Openbravo_Localization_Quality_Assurance_CheckList"

This page has been accessed 8,335 times. This page was last modified on 22 May 2019, at 14:38. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.