Modules Management

Languages:

Modules Management

This document explains how to manage modules in Openbravo. All module management is done through the General Setup || Application || Module Management window, accessing as "System Admin".

The Openbravo Central Repository is the official online source of commercial and community modules that can be installed from the browser, directly into your Openbravo instance.

Note: some modules hosted in the Central Repository are commercial, which means your Openbravo Subscription must be activated before the module can be installed. Many Openbravo-authored commercial modules are free to customers who have activated their professional subscription. Some commercial modules require pre-payment prior to installation. In this case, after payment confirmation but before installing the module, you will need to do an instance refresh. When searching modules to install, commercial modules can be distinguished by the icon bellow the Isntall now button.

Note: active Openbravo Business Partners are issued a partner-specific, limited-used license (aka "golden key") entitling installation of all commercial modules for evaluation, testing, and demonstration purposes. As a partner, you must activate your test instance with the "golden key" that has been emailed to you, and then you will be able to install any module as documented below. Every 30 days you will need to perform an instance refresh to keep using your golden key. Additionally, you will need to do an instance refresh to install a new commercial module that has been added to the central repository since your last instance refresh.

Installation

Installation of new modules is performed from the Add Modules tab in Module Management window.

There are two possible ways of installing a module, remotely or locally.

Remote Install

Remote installation connects to Openbravo Central repository to look for the latest version available of the module to install. It pulls all the module dependencies, installing always the highest compatible version and in case it is needed, updates the currently installed modules to the latest compatible version with the modules to install or update. That's why this is the recommended way of installing modules.

You can look for the module you want to install using the Search text box. When Search button is clicked, the application will connect with Openbravo's Central Repository to look for the modules matching the criteria and will show them, in each module there is a View Details link which will open an information box about the module.

When the module to install is selected and the Install Now button is clicked, the installation process will start.

Install from File System

For those instances that are not connected to Internet or for installing modules that are not available in the Central Repository (for example, a customer's own private modules), it is possible to install modules from the File System.

First of all you need to obtain the module as an obx file and save it in your file system. The obx files for all published module versions can be downloaded from Central Repository.

Once you have the obx file, clicking the Browse File System button will open a dialog window to select the file and afterwards the installation process will start, this process is the same as the explained for Remote Installation. The only difference is that dependencies will not be installed or updated, so in case a required dependency is not included within the obx file and it is not installed in the instance, the process will stop.

Update

In the Installed Modules tab of Module Management window the modules that are installed in the system are displayed, here it is also possible to see information about the modules.

Like for installation, it is possible to update modules remotely and locally.

Remote Update

To update modules remotely, just click on the Scan for updates button. This process will look in the Central Repository for all the latest compatible versions of the modules installed in the Openbravo instance and will show them as update available.

When there are updates available, a message is shown next to each module and on top of the modules box.

It is possible to install the update for just one of the modules by clicking on the link on the left or the module, or to install at once all the available updates by clicking in the link on top of the box. After doing any of these two actions the installation process will start.

Update from File System

Updates through obx files are done, in the same way as installation from file system, from the Add Modules tab clicking the Browse File System button. If in this window is selected a obx file containing a newer version of an already installed module, this module will be updated to this version.

Uninstall

Installed modules can be uninstalled from Installed Modules tab.

To uninstall modules select them in the modules box and click on the Uninistall selected button. This process will remove the module from modules directory, after uninstalling modules a system rebuild is requiered.

Be aware that uninstalling a module removes everything related with the module, including user data in database, so for example if a module includes a database table, this will be dropped with all data it might content.

When uninstalling a package or template, all modules that are included within it will be also uninstalled.

Modules that participate on dependencies for other installed modules cannot be uninstalled unless the ones that define the dependencies are uninstalled as well.

Disable

The contents referred on this sections are available from 2.50MP21

Installed modules can be disabled. This is performed by selecting the modules to disable and clicking on the Disable selected button.

When a module is disabled all the features it defines are not longer accessible. But unlike uninstalling it, the module remains installed so no user data is removed from database and new updates for this module can still be installed (though the module will be kept as disabled).

Enable

The contents referred on this sections are available from 2.50MP21

Disabled modules can be enabled again by clicking on the Enable link that appears next to them.

Enabling a module will make all its features accessible again.

Installation Process

Installation process is executed as part of module install, update or uninstall (see above), it is composed by two tasks: install and rebuild. The execution of these two tasks are necessary to completely install the module, but is is possible execute the second one delayed on time from the first one. Furthermore, it is possible to execute several times install for different modules and to rebuild the system just once for all of them.

Install

Module installation consists on downloading obx files and extracting them to the modules directory. So when this task finishes, the source for the modules are in the system, but they are not still applied to the instance.

This process is executed in a pop up window and involves four steps:

Information about the modules to install or update is shown. These modules will be the ones selected for install or update and for remote install/update all the required dependencies that need to be installed or updated.
Next step will be reading the licenses for all the modules to be installed or updated.
After accepting these licenses the modules indicated in first step will be downloaded and installed in your system.
Finally, it returns to the Installed Modules tab where it is possible to launch the rebuild task.

Rebuild

Be aware that this step requires to stop the server so all users will be kicked out from Openbravo.

After a module is installed or updated, it is required to rebuild the system to apply its changes.

The steps to rebuild are:

Stop Tomcat
In command line, execute: ant update.database compile.complete.deploy. Read more information about build tasks here
Start Tomcat

Advanced settings

Advanced settings can be configured from Settings tab of Module Management window, in most cases it is not necessary to change the defaults for these settings.

Maturity Status

Maturity status is a very important property that module versions (and core maintenance packs) have, which is used to define their life cycle. The value for this property is defined by the module owner.

Introduction

During the life of a module, it can be at different maturity statuses in the Openbravo Central Repository. The maturity status for a version should be promoted after passing some tests and/or being used for some time in a real production instance. Setting the maturity for a version is up to the module administrator.

The possible values version maturity status can have are:

Test: This status is used for versions that have not been completely tested. MP published with this status should be installed only in instances which want to test the solution (staging environments), generally to provide feedback to the Openbravo development team. Versions with this maturity should not be installed in production environments. Openbravo does not recommend releases in this stage for production purposes.
Quality Assurance (QA): During this stage the module has yet to pass all the tests defined by the Quality Assurance standard operating procedure to confirm it can pass to the next stage being QA Approved. A maintenance pack in this stage is also not recommended to be used for production purposes.
QA Approved (QAA): At this stage the version has passed automated tests, all identified issues have been individually verified and the QA team runs a set of manual tests to identify further improvement requirements and to solve identified issues. Despite the fact the release is getting to a stage of being stable, from the perspective of Openbravo this stage in the release cycle is not yet considered ready for generalized deployment for production purposes. We therefore recommend to only deploy releases in this stage for production purposes in case there is a particular interest that requires to do so and with the explicit consent of your client / end user. In conclusion this is only recommended to be deployed in production for those who have a particular interest and explicitly assuring full alignment with the end client.
Confirmed Stable (CS): This is the final stage for a version. At this stage the release has passed the three previous stages of maturity, so it is tested and it has been working during at least 2 months in the QA Approved maturity and is moved to Confirmed Stable without known regressions / important issues. Openbravo recommends all its Partners and end clients to work with releases that have reached this stage of maturity since Openbravo can warrant its stability which we consider key for a mission critical software solution like Openbravo.
Canceled (C): Canceled versions are not available to be installed in any instance.

Maturity Status

Professional and Basic instances are defaulted to just accept versions in Confirmed Stable maturity status.

Community instances are defaulted to accept versions in at least QA Approved maturity status.

It is possible to define a different minimum maturity status for versions to be installed or updated than the default one.

This is controlled by 3 parameters that can be changed in the Settings tab of the Module Management window:

Update Minimum Maturity: It is the minimum accepted maturity status for updates of already installed modules.
Install Minimum Maturity: It is the minimum accepted maturity status for installing new modules.
Module Specific Minimum Maturity: Apart of the two global settings described above, it is possible to overwrite module by module their accepted minimum maturities for update. This can only be set for modules that have already been installed in the instance. In case a module has a specific value, it will prevail over the generic ones. Note that modules contained inside of packs or templates are treated can have different levels of acceptance, so in case it is desired to have accept for all the modules inside a pack a level different than the global one, it will be necessary to add for each of them a specific value.

Important note: If the level of Install global setting is lower than the Update one, it will be possible to install modules having a maturity level, which in case a new version with the same level is published, will not be updatable. To allow updates at this level, it will be required to add a new specific setting for this module.

To better illustrate how it works you can visit the User Stories section of the project functional documentation.

Learn why

Confirmed Stable modules are modules that have been in use with customers for an extended period of time and are therefore proven by real world usage. Restricting access to modules in this status is recommended to organizations that prefer safety over the benefits of adopting new functionality closer to the leading edge of innovation.

Openbravo provides great software to its Community Edition users under an open source license that promotes collaboration between users and developers. In exchange, we ask Community Edition users to help us stabilize our software; we therefore encourage you to stay near the leading edge of innovation and consistently update your system to the most recent version of our code. For this reason, the highest status of maturity that you can restrict in a Community Edition is QA Approved.

QA Approved modules have passed our strict QA process and are safe for production usage.

If you are not interested in automatically staying at the leading edge of innovation, you can manually access Confirmed Stable modules from our source code repositories and install them manually. If you want to restrict your system to Confirmed Stable modules and still enjoy the convenience, automation, and safety of the Module Management window, you should consider subscribing to either Openbravo Professional Edition or Openbravo Basic Edition.

Learn more about the benefits of Openbravo's commercial editions.

Overwrite Dependencies

Overwritting dependencies is risky and should only be done in case you are completely sure about it.

Module owners can define different types of enforcements for dependencies and they can also decide whether they are user overwritable.

Enforcement for dependencies defined as User Editable Enforcement can be overwritten from Settings tab.

In case any of the modules installed in the instance defines a user editable enforcement, this dependency will be shown in the Editable Dependencies section of Settings tab. User is able to change the enforcement for this dependency, once it is selected a different enforcement than the original one (marked as Default), it will overwrite the default one and it will be used when calculating compatibility between modules (both locally and in central repository). If the Default setting is selected, dependency type will be the one defined by the module version and the instance will not overwrite it.

In this way it is possible to freeze a module version making not possible to install newer major versions for it, or in the other way around it is possible to relax dependencies making compatible a newer major version for a module that the owner has not defined as compatible yet.

Be aware of the risk of overwritting dependencies, specially in the case of relaxing them, because in this case, central repository could provide updates for modules that have not been tested to be compatible and it could be possible they not to work with the installed versions.

Languages:

Modules Management

Contents

Template

Usage