Projects:Module Merge Support/Functional Documentation

Contents 1 Headline text 2 Overview 2.1 Purpose 2.2 References 3 Design Considerations 3.1 Assumptions 3.2 Dependencies 3.3 Constraints 4 Glossary 5 Functional Requirements 5.1 User roles & profiles 5.2 Business process definition 5.3 User stories 5.4 Functional requirements based on business processes 5.4.1 Merged Module Installation 5.4.2 Merged Module Publication 5.5 User Interface Mockups 5.5.1 Openbravo ERP 6 Technical Requirements 7 Non-Functional Requirements 8 Closed Discussion Items 9 Testcases 9.1 Planned cases 9.1.1 Code review 9.1.2 Central Repository 9.1.2.1 jUnit 9.1.2.2 Publication 9.1.3 Openbravo 9.1.3.1 Project Branch 9.1.3.2 DBPrefix 9.1.3.3 OBX Installation 9.1.3.4 CR Installation

Headline text

Overview

Purpose

References

Design Considerations

Assumptions

Dependencies

Constraints

This feature will be available from 2.50MP24/3.0RC3. When trying to install a module that includes a merge from central repository, if the Openbravo version is previous to these ones, a proper message (not translatable) will be shown to the user. In case she tries to install it from obx file, merged module will not be uninstalled because of that the rebuild process might fail or the application later might behave unexpectedly. This could be fixed by manually uninstalling the merged module.

This can only be solved by the module developer by defining a dependency to a higher version of core for merged modules.

Glossary

Functional Requirements

User roles & profiles

Business process definition

User stories

Functional requirements based on business processes

Merged Module Installation

• Modules can define which other modules merge. This definition is done by manually entering the merged module UUID as well as its name, it is done in this way because merge module shouldn't be installed in the instance so referential integrity is not possible.
• When trying to install a module (A) that merges another one (B) from central repository, the following cases can happen:
  • B is not installed in the instance: user does not receive any additional information, the module is installed regularly.
  • B is installed in the instance:
    • The instance is previous to 2.50MP24/3.0RC3: an error message is shown not allowing the operation and asking to update.
    • B is part of the dependencies of other modules installed in the instance: A installation is not allowed.
    • B is not part of any other dependencies. A is installed, in the first installation popup a message saying B is going to be uninstalled because it is merged within A is shown. The process installs new version of A and uninstalls B.
• Doing the same from OBX, behaves in the same way. Except the case of an older Openbravo version (<MP24), there the merged module will not be uninstalled because of that the rebuild process might fail or the application later might behave unexpectedly. This could be fixed by manually uninstalling the merged module.

• When trying to install/update a module that has been merged, even the module that merges is not installed, information about not installing/updating to the latest module version is shown to the user.

Merged Module Publication

The following checks will be implemented in Central Repository for publishing modules with merges:

• The merged module must be registered in Central Repository before publishing the one that merges it.
• Merges can only be included in new major version of the module that includes the merge.
• Merges cannot be removed within minor versions of the module that includes the merge.
• Only one DBPrefix is allowed for modules (others than core) unless the module defines a merge, in this case it will be allowed to use the original DBPrefix the module had registered as well as the ones registered for the merged modules.

User Interface Mockups

Openbravo ERP

Technical Requirements

Non-Functional Requirements

Closed Discussion Items

• ICI: If module A merges module B. Highest version of B should be A's highest one. In this way in case A is installed B wouldn't be shown in the search; having B installed but not A, scan for updates would find latest A as an update for current B.
  • ALO: By now this will be done by showing info messages saying you're not in the latest version of the merged modules and telling to install the module that merges.
• ICI: In case a pack is merged, should its inclusions be uninstalled when updating to the merger module? What about in case there are elements belonging to different packs? How it is currently shown in the MMC module tree?
  • ALO: Not to be done.
• ICI: Partially related with merges. In the following scenario, module X1.0.0 depends on Y and Z. When installing X, Y and Z are installed.
  • If X is uninstalled, Y and Z remain in the instance. Should exist a way to automatically clear (uninstall) them?
  • If X2.0.0 does not depend on Z, when X is updated to X2.0.0, Y remains in the instance. Should exist a way to automatically clear (uninstall) it?
  • ALO: To be added to the list of future CR improvements.

Testcases

Planned cases

Code review

• Openbravo ERP: [1]
• Central Repository module: [2]
• check all code affected by the changes
• all 3 WS implementation in CR were changes, check the older ones

Central Repository

jUnit

jUnit test cases for Central Repository can be found at [ https://code.openbravo.com/erp/pmods/org.openbravo.test.centralrepository/ ]

Publication

You can find the obx described in this section: Module-merge-test-modules.zip.

• Prepare 2 modules: A 1.0.0 (DBPrefix TESTA) depends on B 1.0.0 (DBPrefix TESTB), B depends on fake 2.50MP24. Publish them.
• Create A 1.0.1 which contains 2 DBPrefixes (TESTA and TESTB) but does not merge. Publication is not allowed because it has 2 DBPrefixes.
• Create A 1.0.2 which does not depend on B but it merges it, it depends on fake 2.50MP24. Publication is not allowed because a new minor version cannot define a merge.
• Create A 1.1.0 like 1.0.2. Publication is allowed.
• Create A 1.1.1 like 1.1.0 with a third DBPrefix (TEST3). Publication is not allowed because it has an extra DBPrefix which is not defined within the module nor the merged one.
• Create A 1.1.2 with a second merge (module C). Publication is not allowed because new merges cannot be included within minor versions.
• Create A 1.1.3 removing B merge. Publication is not allowed because merges cannot be removed within minor versions.
• Create A 1.2.0 like 1.1.3. Publication is allowed.
• Publish some core obx (to validate you can still publish core having multiple db-prefixes)
• Register & publish an obx using older erp not having those changes (MP23) to see if it accept obx file not having new fields

Openbravo

Project Branch

• Execute integration tests in project branch.

DBPrefix

• Execute integration tests in project branch.
• Create module D without merges (TESTD, TESTE), try to insert 2 DBPrefixes, it is not allowed.
• Define a merge in D. Include the 2 DBPrefixes defined in previous point, it is allowed.

OBX Installation

• In a fresh instance, set core to at least the fake 2.50MP24 rev. Install A 1.1.0. (Defined in CR-Publication test cases). Installation is correct, no additional message is shown.
• In a fresh instance, set core to at least the fake 2.50MP24 rev, install B1.0.0. Create E1.0.0 depending on B1.0.0. Try to install A1.1.0. A message saying it cannot be installed because E depends on B and B cannot be uninstalled is shown, the process stops.
• Uninstall E. Try to install A1.1.0. The first popup says A1.0.0 is going to be installed and B is going to be uninstalled because it is merged within A. The process does it. Check backup of B has been created.
• Having A installed try to install B. It is not allowed as it is merged within A. Check that a proper message is shown.
• Test installation of actual merged module:
  • Without having the merged module installed
  • Having the merged module installed
• To ensure backwards compatibility install Spanish Localization pack. Last time obx installation was changed, a bug preventing pack installation was introduced.
• Update core:
  • from MP23 -> mp24 (having those changes)
  • from MP24 -> dummy newer mp25
• Test installing merged modules with MP23 not having the local changes for this project
  • from CR proper message should be shown
  • from obx, check that what we expect does happen (B merged into A, B not uninstall, but A update done)
• In a fresh instance, set core to at least the fake 2.50MP24 rev. Install A 1.1.0 and B. Upgrade to A 1.2.0, no merging messages are shown, B is kept in the instance.

CR Installation

• In a fresh instance with core previous to fake 2.50MP24. Repeat the cases defined for OBX. Messages saying merges are not allowed should be shown.
• Set core to fake 2.50MP24. Repeat cases for OBX, same results should be obtained.
• In a fresh fake 2.50MP24 instance.
  • Search for B module. In the description, details and clicking on install appears info about it is merged with A. Install it.
  • Publish a new version of B. Scan for updates, in the update info appears info about it is merged, when trying to update this info appears also.

Category: Projects ERP