Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011046Openbravo ERPA. Platformpublic2009-10-20 10:472022-02-01 08:08
Reporterjohnfandl 
Assigned ToTriage Platform Base 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0011046: Make Butler || License >> Modules more efficient for Packs (that have multiple dependent commercial modules)
DescriptionThe Butler module provides a flat (non-hierarchical) structure for commercial modules, which is fine when granting access to a single module. However, multi-module commercial "Packs" contain multiple modules, which makes it very time-consuming and error-prone for the administrator to find and add all of the required modules . For example, the Spanish Professional Localization contains 5 dependent commercial modules, which means a total of 6 records need to be added for each Spanish customer.

Currently, it is not too bad because we don't have many commercial modules to choose from. However, as more commercial modules get added to Butler, it will become a very time-consuming and error-prone process to correctly license packs.
Steps To Reproduce1. Access Butler
2. Enter the modules for the Spanish Professional Localization Pack for 10 customers (that will be 60 rows)

This works for now, but will break in the future as the number of commercial modules and professional subscription customers increases.
Proposed SolutionOne solution is to interface the entire hierarchical module list from the Central Repository server to the Butler server. An option to "Synchronize Module Data from Central Repository" would be provided, which could be executed on demand.

Once the hierarchical module information is present in the Butler database, the Administrator would be able to interact as follows:

1. The Butler Administrator can simply select a Parent module (for example the Spanish Professional Localization Pack), enter any license information (currently Valid From and Valid To dates), i.e. same user experience as now.
2. When the user attempts to save the row, if the selected module contains any dependent (Child) commercial modules that are not already present for the selected License, then:
 2.1 The system will automatically present the Parent Module and a list of all dependent commercial modules, so that the Butler administrator can manually verify that all have been paid for
 2.2 The Butler administrator can now either cancel the entire transaction, or click a button to add the Parent row and all dependent commercial modules

Note that the Parent Module may not actually even be a commercial, assuming it is possible for a non-commercial module to take a dependency on a commercial module.

A weakness of this approach is that adding a new commercial module to a Pack is not handled automatically - which means that every customer has to be touched in this case. An addition to the above approach would be to add a switch called "Automatically License Dependent Commercial Modules" in Butler only (Openbravo needs to control this, so that people creating Packs can't bundle other authors' modules for free). This would make it unnecessary to explicitly license any dependent modules in the future (very good for "open-ended" packs like professional localizations, which will grow over time). This concept would require a change to Openbravo ERP Module Management - to bypass the license checking on dependent modules when the parent module has "Automatically License Dependent Commercial Modules" checked.

From the Butler perspective, when the Butler Administrator has selected a module with "Automatically License Dependent Commercial Modules" checked (which is maintained on the Butler || Commercial Modules screen), then step 2.1 is bypassed (and the dependent rows are not explicitly added to the table).
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-10-20 10:47johnfandlNew Issue
2009-10-20 10:47johnfandlAssigned To => psarobe
2009-10-20 11:57psarobeAssigned Topsarobe => plujan
2009-10-20 11:57psarobeDescription Updated
2009-10-20 12:04plujanProjectQA => Openbravo ERP
2009-10-20 12:04plujanOBNetwork customer => No
2009-10-20 12:04plujanAssigned Toplujan => iciordia
2009-10-20 12:04plujanCategoryQA - General => A. Platform
2009-10-22 13:50iciordiaAssigned Toiciordia => alostale
2017-04-10 14:39alostaleAssigned Toalostale => platform
2022-02-01 08:08alostaleAssigned Toplatform => Triage Platform Base

There are no notes attached to this issue.