Projects:Openbravo Tree Migration
This project will address the last remaining part of the Tree Extension project: the migration of the existing Openbravo trees.
New ADTable Structure
Up until now the treetype column of the ad_tree table was used to associate each ad_tree with its corresponding ad_table. The treetype uses AD_TreeType list reference. This list reference used to contain all the possible tree types. No two tables could share the same treetype.
The new tree infrastructure is not going to use the AD_TreeType list. Now there is an entity for the defined tree types called ADTreeType. Each table can now have several ADTreeTypes associated to it, but only one of them using the ADTree tree structure. An ad_table_id column has been added to the ad_tree table to associate each adtree with its table, making the treetype column effectively deprecated.
Creation and deletion of nodes
The Tree Extension project provides a handler that automatically creates and deletes adtree nodes. Current Openbravo trees do this handling using triggers. We don't want to change that, so a new flag will be added to specify if the creation and deletion of adtree nodes should be handled automatically.
Steps to migrate the existing Openbravo trees
- This query will have to be used in a modulescript to automatically fill in the new ad_table_id column of ad_tree
update ad_tree as tr
set ad_table_id =
from ad_table ta
where ta.treetype = tr.treetype
where ad_table_id is null;
- A new record in the Tree Category window will have to be added for each entry in the AD_TreeType list.
- The new isTree flag will have to be checked for each table that has a not null treetype. This will make the Tree Table subtab visible
- A new record in the Tree Table subtab will have to be added for each of these tables, selecting the corresponding Tree Category.
- The Table Tree field of the Tab tab of the Window, Tabs and Fields window will have to be set for those tabs where the new tree grid view should be shown.
- In the WindowTreeChecks class there are some checks to control if a node reparent is valid taking into account its tree type. This will have to be handled now using the new CheckTreeOperationManager, which adds these checks using dependency injection.
Tree references will be created for all the current tree tables, but they will not be assigned to any columns yet.
QA & Testing
- The proper root nodes are shown for each tree. Check trees in header tabs and in subtabs
- Node reparenting works the same as before, taking into account the custom checks for each tree type
- The ADTreeNodes or the Menu ADTree are properly exported executing ant export.database
- Importing and exporting a client works, and its trees are imported/exported properly
- The continuous integration is not broken
- Volume testing. The new development will be tested in the Apollo database.