Hi all,
A reminder on these best practices.
The Release Management team periodically does a test to check that the
data in subversion is consistent. And if there are problems they commit
the changes. However, they shouldn't have to do any commit if we follow
these practices before committing.
Please don't forget to do a synchronize terminology and translate the
sources when it is necessary. And remember to do an export.database
after we translate the sources to update the xml in sourcedata where
the data of the AD_TextInterfaces table is saved.
Agur
Gorka Ion
-------- Original Message --------
Hi,
I have just made a commit (rev 2359) to fix some problems that have
appeared because we have not take into account a couple of important
things that might be obvious. But when be change something directly in
the xml files we might forget to.
- When we modify/create a manual window, any manual window:
forms, action buttons, reports, selectors,... , we have to remember
to translate it. Or at least to execute the translation task on
compiling time. During the development using the -Dtr=no attribute can
save us time but before doing the commit it is necessary to compile
once translating the sources. The reason is to update the
AD_Textinterfaces and AD_Textinterfaces_Trl tables with the new text
that has to be translated. It will also be a good to translate it to
Spanish when possible.
- When we modify some terminology (name of columns, fields,
help, window names,...) we have to run afterwards the Synchronize
Terminology process from the application (Application Dictionary
folder with System Administrator role). Most of the fields and columns
have their name, description and help centralized in the AD_Element
table. So if we modify directly the column we might lost later the
modification as is happening in the commit that I have done. The menu
items should neither be modified directly as this process also updates
their name with the window, process, report's name that is related to.
We have to remember these two points so later when other people is
developing don't get unexpected changes that haven't done directly when
the database is exported.
Gorka Ion Damián.
|
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development