0040784: provide a consistent mechanism to load messages in client

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0040784

Openbravo ERP

A. Platform

public

2019-05-06 09:35

2022-02-01 08:07

Reporter

alostale

Assigned To

Triage Platform Base

Priority

normal

Severity

minor

Reproducibility

have not tried

Status

acknowledged

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Merge Request Status

Review Assigned To

OBNetwork customer

Web browser

Modules

Core

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0040784: provide a consistent mechanism to load messages in client

Description

Currently, messages defined in AD_Message are loaded in the client side according to one of these two mechanisms:

1. Back-office
  * Messages in core module: only those flagged as "Force Availability in Client"
  * Messages in any other module: all of them are loaded

2. Mobile applications (such as WebPOS or AWO)
  The messages available in the client are [1]:
    * The ones defined in Mobile Core Infrastructure module
    * The ones defined in current mobile application module
    * The ones defined in any module depending (at any level) on current mobile application module

This has some inconveniences:

1. Inefficiencies: messages intended to be used only by backend processes are also loaded in the client
2. Some cases are not covered: for example, having a module A that depends on mobile.core, and a module B that depends on A and WebPOS, messages defined in A cannot be made available in WebPOS client

---
[1] http://wiki.openbravo.com/wiki/Mobile_Internationalization#Available_Labels [^]

Steps To Reproduce

Proposed Solution

There should be a single mechanism to decide which messages are loaded in the client, being the same for back-office and mobile applications.

AD_Message.isIncludeIni18n column should be replaced by another one defining the application the message is for. In case it is null, the message should not be loaded in any client at all (those messages would be only usable from backend processes).

We would need to provide a good mechanism (module script?) to populate this column with proper defaults in order to make a transparent transition where continue being loaded in the client following current rules.

Additional Information