Projects:Support for Commercial Modules/Specifications
Contents |
Support for Commercial Modules - Functional Specifications
Overview
Purpose
Central Repository is going to be enhanced to support Commercial Modules and a most convenient way to download obx files (for modules installation and update). Openbravo ERP must support these new developments, the purpose of this document is to detail the functional specifications for this support.
Scope
There are items to be supported by Openbravo ERP:
- Commercial Modules
- Commercial modules can be only installed/updated from Openbravo Subscription active instances that have an active license for that concrete module.
- High Volume Modules Download
- Currently the installation or update of high volume modules is painful. It is necessary to refactor the way modules are downloaded. After this, it will be possible to update core using the standard UI, as the rest of modules.
References
Specifications for Openbravo Professional Subscription and Central Repository v2 are explained in their own projects documentation.
Design Considerations
Dependencies
This project depends on Openbravo Profession Subscription and Central Repository v2 projects.
Constraints
In Central Repository v2 project is taken into account that after the new developments it is needed to maintain backwards compatibility to support Openbravo ERP instances in older versions.
It is a known issue that even though old Openbravo ERP versions (which all of them will be in Community Edition) won't be able to install/update commercial modules, they will not be able to show a proper message when this is tried to be done.
Functional Requirements
User roles & profiles
This project affects to System Administrators trying to install new modules or upgrade existent ones.
Business process definition
- Non commercial module installation/update: The process should be identical as it was before this project implementation.
- Search modules: Should we identify which are the modules that are commercial and which are the commercial ones the current instance is allowed to update? If so, how?
- Core update: When the scan for updates button is clicked, if there is a new core version available, it is marked in the modules tree (as it is done for the rest of modules) and it is possible to apply it using the UI interface.
Community Edition Instance
- Trying to install/update a commercial module: When a community instance tries to install/update a commercial module, it is not allowed to perform the action. A message explaining the benefits of upgrading the instance to Professional Subscription and the steps to do so is displayed.
Professional Subscription Active Instance
- Installing/updating a licensed commercial module: If the current instance has a license for the module to be installed/updated the process, from the user's point of view, is identical to a non-commercial module installation/update.
- Installing/updating a not licensed commercial module: In case a commercial module which license is not active for the current instance is tried to be installed/updated a message is shown explaining the steps to be performed in order to active this instance and the process is aborted.
User stories
Tom is the system administrator of an Openbravo Community Edition Instance, whereas Jerry administers a Openbravo Professional Subscription Instance.
Tom is looking for a module that allows him to do a human resources management, he searches for modules in the Module Manager Console within the Openbravo ERP application and founds a pair of them that could fit his needs. The first one is non commercial. He decides to install it. The experience he has during the installation is as it was in previous Openbravo ERP versions: he is informed about what is about to install, he is asked to agree the module's license and finally he installs the module.
The second module Tom can see is a commercial one, in this case he can easily identify the module is commercial, and in case he clicks the Install button he will not see the standard installation process windows, but a window with information about how he can upgrade his Openbravo Community Edition to Professional Subscription, and how he could then acquire the license for that module.
Jerry is in the same case as Tom, he also wants a module to manage human resources. As Tom did he uses the Module Manager Console to search for modules and finds the two ones Tom found. He also can differentiate the commercial from the non commercial one. He decides to install the non commercial one, and as Tom, the experience is the same as it used to be.
After that, Jerry wants to install the commercial module because it has very useful extensions. When he clicks in the Install Now button he sees a window with the information needed to obtain the license for this module. He acquires it and comes back to the Module Manager Console, now he can install it in the same way he did with the non commercial one.
Functional requirements based on business processes
| Num | Requirement | Importance | Status |
| 1.1 | Disallow installation of non allowed modules (because they are commercial and the instance is Community Edition or the license for that module is not available for the current Professional Subscription instance). | Must Have | Done |
| 1.2 | Allow core updates through Module Manager Console | Must Have | Done |
| 1.3 | Show a proper message when the module cannot be installed because of license limitation. Two messages to define:
| Must Have | TBD |
| 1.4 | Distinguish visually commercial and not commercial modules when searching and updating. | Nice to have |
User Interface Mockups
TBD
Technical Requirements
| Num | Requirement | Importance | Status |
| 2.1 | In order to allow requirement 1.2, reimplement the way obx files are downloaded from central repository. | Must have | Done |
Open Discussion Items
- In this scenario: Openbravo Community Edition, module A installed in v1 which is non commercial, there is a non-commercial v2 for this module and a v3 commercial version. Which version should be shown in the available updates? If v3, would be possible to update to v2? If v2, should appear somehow that v3 is also available but it is commercial?
- A community user to see both the open source and commercial versions of the module as if they were two separate modules
- Alternatively they would only see the open source version if they have not installed the module and once they have install it they should see the commercial version as an update that they cannot get (visually it should indicate something like - Updated version for Professional Subscribers only). The same applies to Professional Subscribers users who have not acquired a professional version module. Once they have acquired a professional version, they should be able to see and update the latest version as usual.
- Personally, I like more this second approach than the first one.
Closed Discussion Items
- It is pending to decide how the user is informed when a module cannot be installed because of license limitation. It could be done without any notification till the module is tried to be installed, then in the last step: when the module is going to be downloaded show a red box message with the information. This is the easiest approach, if it is not enough it will be necessary to define another one.
- Not changing the visual appearance of the Module Management console and use messages is not good enough. We want people to visually see which modules are commercial and which one are community before they take any action. If they are using a professional edition, they need to also have an easy way to purchase the entitlement key without having to go through too many steps.
- In case we identify modules visually to allowed to be installed or not. How should we manage a module that is not installable because one of its dependencies is not installable? For example a non commercial module depending on a commercial one. Furthermore, as a version of a module can be commercial whereas another version of the same module can be non commercial, CR must take this into account when obtaining dependencies to be installed.
- I would not consider this a major issue and would not worry too much about it. Realistically it would happen only for Core (i.e. a developer releases an open source module but takes a dependency on core at a maintenance pack version that is available only commercially). It is fine if the user attempts to install and gets an error message. On the other hand, it is important that we do not recommend people to upgrade a commercial module that they already have installed to a version that they cannot get because it depends on a version of Core that is not available to them.