Projects:New Types of Dependencies/Functional Documentation

Contents 1 Overview 1.1 Current dependency definition 1.2 Purpose 1.3 References 2 Design Considerations 2.1 Assumptions 2.2 Dependencies 2.3 Constraints 3 Glossary 4 Functional Requirements 4.1 User roles & profiles 4.2 Business process definition 4.3 User stories 4.4 Functional requirements based on business processes 4.4.1 Openbravo ERP 4.4.2 Central Repository 4.5 User Interface Mockups 5 Technical Requirements 6 Non-Functional Requirements 7 Open Discussion Items 8 Closed Discussion Items 9 Testcases 9.1 Code review 9.2 Backwards compatibility 9.3 jUnit 9.4 OBX 9.5 Central Repository 9.6 Others 10 Project status

Overview

Current dependency definition

Currently (<=2.50MP20) dependencies between modules are set in this way:

• There are 2 kind of dependencies
  • Dependency: Defined by a mandatory First Version and an optional Last Version field.
  • Inclusion: Defined only by a Version field which is equivalent to First Version field of dependencies. Inclusions can be set for Packages and Templates, when an inclusion is defined, the dependent module will be packaged in the same obx file than its parent package or template.
• (First) Version field defines the first minor version a module is compatible with.
• In case there is not Last Version, dependency is for all minor versions of the module in the same major version.
• Last Version defines the highest compatible minor version, it is only allowed to be a different major version. This means that in case first and last version are 2 minor versions of the same major version, Last Version field is not taken into account and the dependency is defined as it is was null.

Purpose

This project has two purposes:

• Allow module developers to define new types of dependency enforcement:
  • Major Version: This type of dependency works as the current one does.
  • Minor Version: It works as follows:
    • If not Last Version is set, (First) Version of the dependent module is the only minor version compatible with this one.
    • If there is Last Version, it defines the highest compatible minor version even if it is for the same major version.
  • None: There is not major version limitations, so it versions in a higher major version are still compatible.
• Allow module developers to define whether dependencies are "Editable" by user. If this is allowed, users will be able to overwrite in their instances the default dependency enforcement.

References

Design Considerations

Assumptions

Dependencies

Constraints

Glossary

• Module Version: A module version is defined by 3 integer numbers separated by periods (for example 2.50.17000, 1.0.0, 0.2.3, etc). If this 3 numbers are x.y.z, x.y is the major version and z is the minor version.

Functional Requirements

User roles & profiles

There are two roles affected by this project:

• Module Owner: Is the person in charge of creating modules and defining their dependencies.
• Openbravo ERP System Administrator: Is the person that installs and updates modules in an Openbravo ERP instance. He is able to relax or increase strictness for dependencies.

Business process definition

User stories

Smee is the Taxes for Neverland and the Taxes for Neverland Neverlandese Translation developer. Peter is the Neverland Localization Pack developer which includes Smee's modules.

The translation is a quite small module, so Smee decides to set the enforcement of the dependency to Taxes for Neverland as None, in this way when, in future, he publishes new major versions for Taxes module they will be still compatible with the current translation, making not needed to publish a new major version for the translation. Smee published version 1.0.0 of both modules.

Peter tests them and as they work fine he includes them in his pack. To ensure no other Taxes version is installed with the Pack, he marks the inclusion of Taxes for Neverland as Minor Version Enforcement but he wants to leave up to the user to use it with newer versions so it checks User Editable Dependency. Finally he publishes Neverland Localization Pack version 1.0.0.

Wendy is an Openbravo ERP Administrator from Neverland. She searches for Neverland Localization Pack and she finds version 1.0.0 and she installs it.

Smee publishes new 1.0.1 version of Taxes for Neverland and Peter starts working in his pack's new version.

At this moment when Wendy scans for updates doesn't find Taxes 1.0.1 because it cannot be installed together with Localization Pack 1.0.0 because of the Minor Version enforcement.

She can relax the enforcement to of dependency to from Localization Pack to Taxes Module to Major Version, after doing so she scans for updates and she can see there is a new version for Taxes which can be installed in her instance.

Functional requirements based on business processes

This project affects Central Repository and Openbravo ERP.

Openbravo ERP

• Module Dependency Definition. These values are part of the dependency definition so they are packaged within the module:
  • Dependency Enforcement, with possible values of "None", "Major Version" (default) and "Minor Version".
  • User Editable Enforcement. A boolean value (false by default) which allows users, in case it is true, to overwrite default enforcement.
• Instance specific enforcement. In case the dependency enforcement is user editable, this field will contain the instance specific value. This value, as is instance information will not be exported as part of the module.
  • MMC Settings Tab. Instance specific enforcement is defined within Settings Tab. Here, a new table with all the User Editable dependencies is shown. For each dependency the default enforcement appears, and the other ones can be set. In case default is selected, no instance enforcement is used, if other value is selected, it will be used as instance specific.

Central Repository

• Information about Module Dependency Definition (see above) is saved in CR DB as part of the module information.
• Information about instance specific settings for strictness is got from ERP when scanning for updates or installing new modules.
• This information is taken into account to calculate consistency.

User Interface Mockups

Technical Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

• ALO: Should be allowed in new minor versions change strictness for a dependency?
  • PJU: I think so. I do not see a problem with allowing it.
• ALO: When a modification in strictness is done at instance level, should this change be preserved over different version of the module? For example if I have in my instance Neverland Localization Pack 1.0.0 and I relax the dependency on Neverland Taxes, when I update localization to 1.0.1, the setting I had for taxes should be maintained?
  • PJU: Yes, it should be preserved. The only case when it should be lost is if the module owner changes the User Modifiable Enforcement field from Yes to No.
• ALO: Does it make sense to allow user to make the dependency strict in case it is not defined in this way? In which case could this be useful?
  • PJU: Yes, it makes sense. Suppose that we decide to ship QuickStart with dependency enforcement set to Major Version; a more conservative user might decide to upgrade only from "distribution to distribution" by changing dependency level to "Minor Version" for all the QuickStart modules.
• ALO: Disabling strict dependencies from UI, allows the user install a new version at her own risk. But this is still only applicable for modules in the same major version. Wouldn't be useful to allow in UI an even more relaxed dependency which allows to install new major versions of the dependency?
  • PJU: Good idea. I incorporated it in the design above with the "None" level.

Testcases

Code review

• Openbravo ERP
• Central Repository module

Backwards compatibility

• Execute existent jUnit tests in pi before mergeing.
• Install old obx file (without new enforcement info).
• Install old CR module (without new enforcement info).
• Publish in CR old obx without new fields. Check dependency enforcement is MAJOR.

jUnit

• There are 10 test cases for this project. Ensure they are passed.

OBX

Pre-test Prepare the following obx:

• Bank Account Search-0.0.5. Depends major enforcement core 2.50.10450. User editable enforcement.
• Bank Account Search-0.0.6. Depends major enforcement core 2.50.10450-2.50.10485. User editable enforcement. (Should work as 0.0.5, last version not taken into account).
• Bank Account Search-0.0.7. Depends minor enforcement core 2.50.10450-2.50.10485. User editable enforcement.
• Bank Account Search-1.0.0. Depends major enforcement core 2.50.10450. User editable enforcement.
• Bank Account Search-2.0.0. Depends major enforcement core 2.50.10450. User editable enforcement.
• Bank Account Search Template-1.0.0. Depends major enforcement Bank Account Search-0.0.5. User editable enforcement.
• Bank Account Search Template-1.0.1. Depends major enforcement Bank Account Search-1.0.0. User editable enforcement.

Test: install from file sytem

• Install Bank Account Search-0.0.1 from obx file. Old version without enforcement.
• Update to Bank Account Search-0.0.5.
• Try to change to minor local enforcement. It shouldn't be allowed because the instance wouldn't be consistent.
• Change manually dependency of installed 0.0.5 to your current core version and set local enforcement to minor.
• Try to Update to Bank Account Search-0.0.6. Not possible, local enforcement prevents it.
• Put back the local enforcement to the default Major and update to Bank Account Search-0.0.6. Now it is allowed.
• Try to install Bank Account Search-0.0.7. Not possible because core version is not in the range.
• Change local enforcement for this module to none (in settings tab). Install it.
• Install Bank Account Search Template-1.0.0.
• Install Bank Account Search Template-1.0.1. Not possible depends on non-installed Bank Account Search 1.0.0.
• Change local enforcement for Bank Account Search Template-Bank Account Search to none and try to install Bank Account Search Template-1.0.1. Not possible depends on a higher version.
• Install Bank Account Search 2.0.0.
• Remove local enforcement for Bank Account Search Template-Bank Account Search and try to install Bank Account Search Template-1.0.1. Not possible depends on a lower major version.
• Change local enforcement for Bank Account Search Template-Bank Account Search to none and try to install Bank Account Search Template-1.0.1. Now it is possible.

Central Repository

• Uninstall bank account search and template modules.
• Install Bank Account Search (0.0.1) from CR. Old obx version without new fields.
• Publish Bank Account Search-0.0.5
• Update to Bank Account Search-0.0.5
• Try to change to minor local enforcement. It shouldn't be allowed because the instance wouldn't be consistent.
• Change manually dependency of installed 0.0.5 to your current core version and set local enforcement to minor.
• Publish Bank Account Search-0.0.6
• Scan for updates doesn't find an update because of local minor enforcement
• Put back the local enforcement to the default Major and update to Bank Account Search-0.0.6. Now it is allowed.
• Publish Bank Account Search-0.0.7.
• Scan for updates, no update available.
• Change local enforcement for this module to none (in settings tab). Install it.
• Publish Bank Account Search Template-1.0.0.
• Install Bank Account Search Template-1.0.0.
• Publish Bank Account Search-1.0.0 and Bank Account Search Template-1.0.1.
• Update to Bank Account Search Template-1.0.1. It is possible because it pulls Bank Account Search-1.0.0
• Publish Publish Bank Account Search-2.0.0
• Scan for updates, no update available
• Change local enforcement for Bank Account Search Template-Bank Account Search to none
• Scan for updates, now Bank Account Search can be updated to 2.0.0

Others

• Pass builds try
• Test settings tabs in IE and FF.

Project status

This project has been merged back to pi and will be included in 2.50MP21.

Category: Projects ERP