Projects:Modularity/ProjectPlan
Iterations
The Modularity project has been split into five sequential iterations each of them including tasks assigned to different developers and a set of test cases. Third and fifth iterations will be merged to trunk.
Iteration | Description | Test cases | Merge to trunk |
1 | Setup all infrastructure for module content except reference data. Packs and industry template are not supported at this point. Implement the build process -including database creation- of an instance with installed modules. Implement the update database process when new modules are installed or applied modules are updated or uninstalled. Have a clear vision and definition of the whole project | Create from OB UI at least three modules. Check that only "in development" modules are available to assign to AD components. Add to these modules at least one AD component of every type (a table, a column in a not owned table, a window, a tab in a not owned window, a field in a not owned tab, ...). Describe dependencies between these modules and core. At least one new module should depend on the other ones. Get the list of licenses that a module can use -from Paolo- and create that list in the AD. Add to these module software resource of every type (jasper reports, java code, jar library, javascript, css, ...). Add also -manually- db schema objects of every type to these modules. Create the database using dbSourceManager from the description in installed modules. Update a module and update the database. Remove a module and update the database. Build the system with the three modules installed and check that everything works fine (at database and application level). Save the module descriptions to be used in future tests. | No |
2 | Modify export utility in DB source manager to take into account modules. Implement the central repository services. First version of the Module Manager Console (MMC). Export/import tool for standard reference data ready to be used in module installation and initial client setup. | Using the instance installed in the previous test case, export it -marking modules in development- using dbSourceManager and compare it with the manual code used to generate it. Add additional changes at database level for every schema object type (table, column, index, constraint, trigger, stored procedure, ...) and export again. Get the exported files in modules and manually copy them to a clean instance and build the system to check that it apply the content in those modules. Register those modules in the Central Repository and publish them. See the installed modules and detailed information of each of them from the MMC. Test the export/import tool and prepare a reference data set to be used in modules (Spanish taxes). | No |
3 | Third version of MMC: implement the search and install modules and apply them to the instance, so it should be possible to install and uninstall modules from the OB UI. Module developers guide ready to be used. Initial client setup modified to support modules. First steps in the tool to generate the standard configuration script. | Material to be prepared before doing the real user test:
From OB UI: install a fresh Openbravo ERP instance. Using the MMC install modules in different combinations (one by one, all together, with dependencies not satisfied, uninstall, ...) and check the system always works consistently. Apply reference data to clients by Initial Client setup and Reference data loader. Update those data using the update tool. Ask to a senior consultant in consulting unit to build some modules using the Developers guide. | Yes |
4 | Module manager console supports packs and Industry templates. It also allows to update installed modules. The tool to generate the configuration script is ready to be used (and tested :-). Initial Organization Setup ready to be used (and tested :-). | Material to be prepared before doing the test:
Test: install the Spanish localization pack and check. Uninstall and check. Install again. Do some changes in application dictionary and database objects. Get the configuration script for those changes. Include the configuration script in the theoretical Industry Template (Spanish localization pack + those changes). Install the Industry Template in a clean instance and check. Perform some customization on top of that and export. Update a module in the Industry Template and update the instance. | No |
5 | Project completion. MMC supports all types of modules and content, including reference data. The tool to migrate old Openbravo ERP instances to the new modular paradigm (2.50) is ready to be tested. Initial client setup and loading mechanisms can be customized from modules using "adaptors". There is a tool to load and update data at Organization level from modules. | Material to be prepared: collect all modules, packs and Industry Templates form previous tests (suggestion: QA should use a different set based on the ones developed by consulting to ensure maximum coverage in the testing processes).
| Yes |
Detailed plan
Sub-project | Task | Responsible | Estimated effort (days) | Iteration | Spec | Build | Test | Test cases | Comments |
1. AD Module structure | 1.1. Create module structure in application dictionary | ALO | 1 | 1 | Complete | Complete | N/A | ||
1. AD Module structure | 1.2. Assign AD components to modules: include a mandatory field pointing to the module they are assigned to | ALO | 1 | 1 | Complete | Complete | N/A | ||
1. AD Module structure | 1.3. Complete module structure in AD with all remaining details | ALO | 1 | 4 | 2 Oct | Complete | N/A | ||
1. AD Module structure | 1.4. Add "registration process" to module window | ALO | 0.5 | 5 | Complete | Complete | |||
1. AD Module structure | 1.5. Validate that modules that are not in development are not modified. Do it with triggers. | ALO | 0.5 | 5 | N/A | Complete | |||
1. AD Module structure | 1.6. Add to system a check to allow modifications, when this check is set a new template should be created. Additionally, create a window for ad_system table to operate this. | ALO | 0.5 | 7 | |||||
1. AD Module structure | 1.7. Prevent some modifications (name, package, db_prefix...) for a module once it is registered. | ALO | 0.5 | 6 | Complete | ||||
2. Build process | 2.1.1 Create structure: load the whole structure from xml files and persist it in DB. It does not take into account partial elements (columns,indexes...) nor configuration script | AMO | 1 | 1 | N/A | Complete | Complete | test-db1: A module made of several new db objects (a table, a function, a trigger and a view), with sourcedata | |
2. Build process | 2.1.2 Create structure: load the whole structure from xml files and persist it in DB. Take into account configuration scripts | AMO | 1 | 5 | N/A | Complete | |||
2. Build process | 2.1.3 Create structure: load the whole structure from xml files and persist it in DB. Take into account partial elements (columns,indexes...) | AMO | 1 | 1 | N/A | Complete | Complete | test-db1, extended with additions to a table (columns, unique constraints, foreign keys, check constraints) | |
2. Build process | 2.2. Update structure: read xml model and compare with db one to update it | AMO | 1 | 1 | N/A | Complete | Complete | test-db1 | |
2. Build process | 2.3. Modify build.xml to take into account resources (for compilation, translation...) | ALO | 2 | 1 | Complete | Complete | Complete | test1: includes a report with html, xml, java, xsql and jrxml files. | |
2. Build process | 2.4. Modify ODE to manage these resources (ensure packaging is correct, .classpath, ...) | ALO | 2 | 1 | Complete | Complete | Complete | test1 | |
2. Build process | 2.5. Create a process to export an installed module as an obx file | ALO | 1 | 3 | N/A | Complete | N/A | ||
2. Build process | 2.6. Export process should export all the objects needed by the module (data sources, reference data...). In the exportation process for packs and templates the includes modules should also be exported as independent obx files. | ALO | 1 | 6* | Complete | ||||
2. Build process | 2.7. Create a user interface for exporting configuration scripts | ALO | 1 | 7* |
| ||||
3. Export process | 3.0. Define how to describe the elements that are considered source data. Take into account if they are linked to modules | ICI | 1 | 1 | Complete | N/A | N/A | ||
3. Export process | 3.1. Export DB objects: Create object filters based on module name and export following this filters. These filters could be designed as pairs of prefix and path. In case AD information about module and physical name do not match show a warning | AMO | 3 | 2 | N/A | Complete | Complete | test-db1, with added AD_MODULE entry. | |
3. Export process | 3.2. Define Core dataset | ICI | 1 | 2 | Complete | Oct 1st | Oct 1st | ||
3. Export process | 3.3. Define which elements could go to the configuration script | ICI | 1 | 2 | Complete | Oct 1st | Oct 1st | ||
4. Reference data | 4.1. Complete technical design on reference data | ICI | 1 | 2 | Oct 1st | N/A | N/A | ||
4. Reference data | 4.2. Export/import tool for standard reference data | MTA | 5 | 2 | |||||
4. Reference data | 4.3. Automate at installation time the loading of other reference data included in installed modules (translations) | ALO | 1 | 5 | Complete | Complete | |||
4. Reference data | 4.4. Modify Initial Client Setup UI to load reference data included in installed modules. Allow the user to optionally load these data. All the backend processes related to modules are mocked implementations | EAR | 4 | 1 | N/A | Complete | N/A | ||
4. Reference data | 4.5. Create the UI of a process to update reference data in clients and organizations from modules. All the backend processes related to modules are mocked implementations | EAR | 1 | 2 | N/A | 10th Oct | N/A | ||
4. Reference data | 4.6. Create an Initial Organization Setup to load reference data included in installed modules. Allow the user to optionally load these data | EAR | 5 | 4 | N/A | Complete | N/A | ||
4. Reference data | 4.7. Implement in real the backend processes related to modules (replacing mocked implementations) | EAR | 3 | 3 | N/A | 17th Oct | 17th Oct | ||
4. Reference data | 4.8. Create a process to update reference data in organizations from modules | EAR | 2 | 5 | N/A | 17th Oct | 17th Oct | ||
4. Reference data | 4.9. Support localization team in the development of reference data stuff | ALO | 1 | 5 | N/A | N/A | N/A | ||
4. Reference data | 4.10. Create DataSets model (Tables and windows). | GGI | 1 | 2 | Complete | Complete | N/A | ||
5. Customize loading mechanisms | 5.1. Hooks for Initial client setup and import loading processes. Eg. How to change the list of document types loaded in a client through a module? It should support adding new document types but also modify the ones loaded in the standard initial client setup | MTA | 3 | 5 | |||||
6. Central repository | 6.1 Define infrastructure and services | ICI | 1 | 1 | Complete | N/A | N/A | ||
6. Central repository | 6.2 Setup a reliable environment (share with heartbeat?) | eProjects | 1 | 2 | Complete | N/A | N/A | ||
6. Central repository | 6.3 Implement module registration, publishing, updating and querying services | GGI | 9 | 2 | Complete | Complete | Complete | ||
7. XML structure for packs | 7.1 Define xml structure for packs and industry templates | ICI | 1 | 3 | Oct 2nd | N/A | N/A | ||
8. Configuration script generator | 8.1. Define elements included in the script (clean, dirty, useless). Define how to deal with reference data -if needed-. | ICI | 1 | 1 | Complete | N/A | N/A | ||
3. Export process | 3.2 Export AD elements using the DAL objects | AMO | 2 | 3 | N/A | Complete | The task is complete, but it is not used yet, as it needs a defined Core dataset. | ||
8. Configuration script generator | 8.3. Read the whole structure from DB and XML and compare both models (take into account that DataColumnChange has to be modified to preserve the entire row) | AMO | 5 | 3 | N/A | Complete | |||
8. Configuration script generator | 8.5. Define a XML structure for data modifications and prepare DBSM to export differences in data | AMO | 4 | 4 | N/A | Complete | |||
8.6. Change the way database data is updated, so that only specific changes are applied to the database, instead of deleting and inserting everything. | AMO | 2 | N/A | Complete | |||||
Properly manage audit info | AMO | 2 | 5 | N/A | Complete | Complete | |||
9. Migration process for current ob instances | 9.1. Define process to ensure that current ob instances smoothly migrate to the new paradigm | ICI | 1 | 3 | Oct 3rd | N/A | N/A | ||
9. Migration process for current ob instances | 9.2. Export data differences: Export modules and load and compare DB and xml files, use the filter for the comparison | AMO | 2 | 5 | N/A | Complete | |||
9. Migration process for current ob instances | 9.3. Export model differences: define a XML structure for all the possible (41) modifications and export them | GGI | 10 | 4 | 22 Oct | ||||
9. Migration process for current ob instances | 9.4. Export other resources (for dirty script) | GGI | 5 | 5 | 29 Oct | ||||
10. Module manager console | 10.1. Define look&feel and UI for the window | ICI | 1 | 1 | Complete | N/A | N/A | ||
10. Module manager console | 10.2. First version: see installed modules in a tree structure, properties of a given module (full description, license, author, ...) | ALO | 2 | 2 | Complete | Complete | N/A | Keyboard navigation for tree component pending (DBA) | |
10. Module manager console | 10.3. Second version: apply installed modules (compile and deploy) | ALO | 3 | 3 | Complete | Complete | N/A | ||
10. Module manager console | 10.4. Third version: search and install modules (without reference data), including remote and local sites to provide the module. Keep installation history | ALO | 5 | 3 | Complete | Complete | 1 Oct | Depends on 6.1, 6.2 and 6.3 | |
10. Module manager console | 10.5. Fourth version: search for updates (module by module, all together) | ALO | 1 | 4 | Complete | Complete | Depends on 6.1, 6.2, 6.3 | ||
10. Module manager console | 10.6. Fifth version: Support for packs and industry templates | ALO | 2 | 4 | Complete | Complete | |||
10. Module manager console | 10.7. Sixth version: Support for reference data. Module manager console will only extract the info in the correct directory, after that in the Apply process the reference data for system client is loaded. | ALO | 1 | 5 | Complete | Complete | |||
10. Module manager console | 10.8. Improve tree UI adding dotted lines | ALO | 1 | 5 | Complete | Complete | N/A | Nice to have | |
10. Module manager console | 10.9. Improve tree UI adding scroll to div in order to be able to go directly to the update description. | ALO | 1 | 5 | Complete | Complete | N/A | Nice to have | |
10. Module manager console | 10.10. Improve tree UI propagating the update icon to the parent nodes. | ALO | 1 | 7 | Complete | Nice to have | |||
11. Developer's guide | 11.1. Write documentation to describe how to develop a module, pack and Industry template | ICI | 5 | 3 | |||||
12. Collaterals | 12.1. Modify the translation process (export/import) to have into account modules (translations should be done at module level) | GGI | 1 | 1 | N/A | Complete | Complete | test1: export language from a module. test2: export language from a table with a parent table. test3: import language. | |
12. Collaterals | 12.2. Allow modules to implement new web services | ALO | 2 | 6 | Complete | ||||
12. Collaterals | 12.3. Allow modules to extend web.xml file. This extension should be done using a new type of Model_ojbect for non-servlet objects, additionally it might be required to add the ad_module_id column to ad_moduel_object table to manage this new type of objects. | ALO | 2 | 6 | Complete |
| |||
12. Collaterals | 12.4. Review order calculation for menu, fields and tabs | ALO | 2 | 7 | |||||
12. Collaterals | 12.5. Prevent modifications in seqNo for fields and menu entries | ALO | 1 | 5 | N/A | Complete | |||
12. Collaterals | 12.6. For webservices implementation it is needed to copy configuration files from to WebContent directory, these files currently are only in config core directory, modules should be able to have this directory too and copy its contents. | ALO | 0.5 | 5 | N/A | Complete | |||
Change the way models are loaded to allow partial model loading. | AMO | 5 | 6 | ||||||
Remove column ordering and add a new formatter selection based on the object class instead of the model information in export process, to avoid model loading and greatly speed up the process. | AMO | 2 | 6 | ||||||
Verify the downloaded obx file is not corrupt using a MD5 hash or something similar. | ALO | 2 | 7 | ||||||
Currently the installation process reads the module information from the xml files included in the obx files and uses DBSM classes to persist it to database, it should be done using DAL classes instead. | ALO | 2 | 8 |
| |||||
Dirty configuration script | AMO | ||||||||
Change format of XML files | AMO | ||||||||
Redefine as members of the application dictionary tables AD_ALERTRULE, AD_TREE, AD_TREENODEBP, AD_TREENODEPR | AMO | ||||||||
Review the orphan entries in the Model Object table to be sure that there is no missing entry in the web.xml file | ICI | ||||||||
Add validation: only references of type List Validation and Table Validation can be included in a module different to core | ALO | 6 | Complete | ||||||
Add validation: search keys in messages should start by the module db_prefix in a module different to core | ALO | 6 | Complete | ||||||
Review translation process: ensure that text interfaces entries are created assigned to modules properly (taking into account the packaging of the file) | ALO | 6 | Complete | ||||||
Create a new method to obtain all the modules ordered by dependencies | ALO | 6 | Complete | ||||||
Read dataset in order when importing reference data applying modules | ALO | 6 | Complete | ||||||
Add validation: ad_table.tablename, ad_table.name and ad_column.columnname must start with the module's db prefix. | ALO | 6 | Complete | ||||||
Apply modules when creating/updating db. | ALO | 6 | Complete | ||||||
Read dataset in order when importing reference data in initial client/org setup | EAR | 6 | |||||||
Manage module dependencies when importing reference data, not allowing to load data that does not fulfills dependencies. | ALO | 8 | |||||||
Declare and manage incompatibilities between modules including different versions of the same jar library | ICI | 8 | |||||||
Take into account workflows in synchronize terminology process. | ALO | 7 | |||||||
Remove AD_Module_Version* tables from Openbravo ERP, they only make sense in CR. Manage properly updates available in the scan for updates process. | ALO | 6 | Complete |
| |||||
Remove AD_Module.IsActive template column which is not used. | ALO | 6 | Complete | ||||||
Prevent updates from MMC for modules that are in development. | ALO |
|