Translation support when using Jasper reports

[Martin Schönbeck]

Hi,

when creating multi language documents with jasper reports it would be helpful to have certain plaintext components in the database together with the translation support of idempiere. My first idea was to use ad_message but that by default only accessible to system users.

Of course it's easy to setup a table comparable to ad_message but perhaps it's a good idea to have something in core.

What do you think?

Regards,

Martin

[Heng Sin Low]

https://wiki.idempiere.org/en/NF9_AD_Resource_Bundle_For_Jasper_Report

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/7c9aac82-d235-44d0-bcb2-249e75fd1118n%40googlegroups.com.

[Martin Schönbeck]

Hi Heng Sin,

I must admit that I didn't fully understand

https://wiki.idempiere.org/en/NF9_AD_Resource_Bundle_For_Jasper_Report

but what I understood is that it depends on ad_message which actually couldn't be change by a client-user.

Regards,

Martin

[Heng Sin Low]

Alright, you are talking about tenant level translation. That's not jasper report specific but an application level feature that we don't have now. Nicolas has raised this before, not sure whether he has made any progress on this.

--

You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/d1688380-e74f-4d58-b33f-23916853c6f3n%40googlegroups.com.

[Nicolas Micoud]

Hi,

No progress.

Idea is to have AD_Message available at tenant level (thrgouh a AD_UserDef_Message

Then add a MUserDefMessage.getBestMatch (Properties ctx, int AD_Message_ID) method.

At the end Msg.getMsg methods should check content of both tables (AD_Message / AD_UserDefMessage)

Another approach would be to be able to change AD_Client_ID on AD_Message_Trl

AD_Element is tougher as you need to also manage translation for fields, process parameters, ... :-/

[Carlos Antonio Ruiz Gomez]

Hi Nicolas, it can be concerning how would that impact the performance and memory footprint.

Because AD_Message is fully loaded in cache (Msg.initMsg) and accessed from there, probably not a big deal, but something to take into account.

I'm wondering if a different approach can be easier, I would suppose messages customized are an exception:

1 - create a window to maintain AD_Message_Trl in tenants, allowing to create specific translation record

2 - in the Msg.initMsg load additionally the AD_Message_Trl tenant records but the AD_Message formatted something like [clientID]|[Value]

    I mean, for example the cache message "AccessCannotDelete" will have the same current record with value "AccessCannotDelete", but if customized in GardenWorld, it will additionally have a cache entry for "11|AccessCannotDelete"

3 - in the Msg.getMsg methods you can look first for a tenant-customized message and if not found then look for the general.

    I mean, Msg.getMsg running in GardenWorld will look first for "11|AccessCannotDelete" and if not found will look for "AccessCannotDelete"

4 - to make things faster for people that don't tenant-customize messages (the majority I guess) we can make explicit using a SysConfig key that tenant messages must be checked

Regards,

Carlos Ruiz

El 3/1/22 a las 7:18, Nicolas Micoud escribió:

[Nicolas Micoud]

Hi Carlos,

What about mixing both approaches :)

#1 - the window

I haven't tested, but not sure about the behaviour of a window with first tab based on a translation table at tenant level and master data set at System.
That's why I would tend to use a AD_UserDef_Message table "Message customization"

Columns:

 - AD_Client_ID

 - AD_Org_ID (must be 0, not updateable)

 - AD_Message_ID

 - AD_Language

 - MsgText

 - MsgTip

Having it at tenant level is enough, but if somebody is interested, there will be place to add AD_Role_ID, AD_User_ID and let AD_Org_ID be updated.

If you prefer to have a AD_Message_Trl tenant level window, is ok for me.

#2 & #3

I've made a test and is possible to save a message with Value = "11|test".
Maybe we should add a check on MMessage.beforeSave to be sure AD_Message.Value doesn't start with a numeric + |  ?

#4 SysConfig

Instead of using a SysConfig, maybe this could be determined by the Msg.initMsg itself ?

We can add a new cache that will contains ClientIDs with customized messages, so they will be taken in account right after a ResetCache run (all customization records are usable instantly).
On the other hand, it can be a way to prepare translations and "activate" them when ready.

wdyt?

Regards,

Nicolas

[Carlos Antonio Ruiz Gomez]

> #1 - the window

> Having it at tenant level is enough, but if somebody is interested, there will be place to add AD_Role_ID, AD_User_ID and let AD_Org_ID be updated.

It doesn't sound good, messages must follow some consistency, tenant level is probably OK, but having different messages per role/user/org is probably over-engineering and it can cause issues trying to support a system where different users view different messages.

I don't see the need of the AD_UserDef_Message, probably just required to make AD_Message_Trl tenant usable - but you can test to see which approach is simpler/better.

> #2 & #3

> I've made a test and is possible to save a message with Value = "11|test".
> Maybe we should add a check on MMessage.beforeSave to be sure AD_Message.Value doesn't start with a numeric + |  ?

Yes - no problem if you want to add such validation.

> #4 SysConfig

I suggested a SysConfig because I believe 99.99% of the implementations out there will not use this message customization.  So the simplest is to make it disabled by default, and whoever wants to use that simply enable that SysConfig and it will have some extra performance/memory concerns.

I would prefer to avoid checking for the existence of tenant-custom-messages every time if is not used specifically by the implementor.

Regards,

Carlos Ruiz

El 3/1/22 a las 15:00, Nicolas Micoud escribió:

[Nicolas Micoud]

Ok, I'll work on that basis ; ticket created https://idempiere.atlassian.net/browse/IDEMPIERE-5136

As it should not be too disruptive (it should only add some code if a SysConfig is set), is it ok to set migration script on i9 ? or do you prefer ID10 ?

Thanks

Nicolas

[Carlos Antonio Ruiz Gomez]

i9 sounds OK if not disruptive

El 3/1/22 a las 16:56, Nicolas Micoud escribió:

[Nicolas Micoud]

Hi,

I made a quick test and it seems to work as expected - I was able to change the label of the "Home" main tab, which was the initial request :)

I change the DataAccessLevel for AD_Message_Trl from System to System+Client.

Only weird thing is records created/updated from the new window are not displayed on "Recent Items" panel.

I think is because there is no AD_Message_Trl_ID column.

I will also need to adapt ad_message_trl_pkey from "ad_message_id, ad_language" to "ad_message_id, ad_language, ad_client_id".

I'll try to finish that tomorrow

Regards

Nicolas