| *** muriloht <muriloht!c8a19c33@gateway/web/freenode/ip.200.161.156.51> has joined #idempiere | 00:05 | |
| *** nmicoud <nmicoud!~Nicolas@riv38-2-78-235-108-177.fbx.proxad.net> has joined #idempiere | 05:18 | |
| *** a42niem <a42niem!~niem@p578b7daf.dip0.t-ipconnect.de> has joined #idempiere | 05:43 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has joined #idempiere | 07:05 | |
| *** CarlosRuiz <CarlosRuiz!~CarlosRui@aftr-37-201-194-235.unity-media.net> has joined #idempiere | 08:52 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has quit IRC | 09:33 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has joined #idempiere | 09:38 | |
| norbertbede | hi team | 09:57 |
|---|---|---|
| norbertbede | i have the next problem/idea | 09:57 |
| norbertbede | when customer asking at beginning "can you anything customise and translate according my requirement ?" we answer yes. however in cloud/multitenant architecture this is problematic. | 09:57 |
| norbertbede | we have window customisation, and can translate print formats, but as i know nothing more | 09:57 |
| norbertbede | the idea is. | 09:57 |
| norbertbede | add a new table - e.g. ad_Translation hierarchy, where we can define on tenant level relations eg. ad_element_id=10 mapr to ad_element_id=100023. then a plugin injected into translation rendering - replace terms. to tenant defined terms | 09:57 |
| norbertbede | this should be applied to elements, messages well. | 09:57 |
| norbertbede | when client login then plugin automatically translate - let say apply translation hierarchy. and return modified awaited translations | 09:57 |
| norbertbede | probably the hierarchy should be implemented on tenant/role/org/user level | 09:57 |
| norbertbede | wdyt ? can be implementable ? | 09:57 |
| norbertbede | i discussed about that wuth deepak. he has idea simple add additional translation instead replace elements id | 09:58 |
| norbertbede | and do not implement on role level.. | 09:58 |
| CarlosRuiz | Hi norbertbede - the requirement is not clear for me - do you have an example of something that you want different on tenant and cannot do it with the actual tools? | 10:38 |
| norbertbede | eg our customer hate pricelist 3 fields | 10:41 |
| norbertbede | he hate limit price - we understand that can be variose usage. but usuallz 1 companz = 1 meaning e.g. Average Price (we update when recalculate limit field) - so in this case we should change limit price everywhere | 10:42 |
| norbertbede | second example same pricing issue - list price something is additional level usage. we implement readonly logic and flag to keep all list price as std price - then no maintenance overhead - later we hide it. in this case he dont like to see standard price but "Sales Price" | 10:44 |
| norbertbede | im tired to faiting with customer - so atm i decide to found a global solution to have ability for centralised tenant translation | 10:45 |
| norbertbede | window customisation is not an option because info windows, forms are still not translated | 10:45 |
| norbertbede | print formats can be problematic if we have 30 reports in client 0 shared across tenants then still i need make copy and maintain it separately - instead allow make tenant translation for elements and messages across all places where translation are handled | 10:47 |
| CarlosRuiz | so - your idea is that any table that has AD_Element look first for this tenant-element-translated-table | 10:48 |
| norbertbede | yes, same for messages | 10:52 |
| CarlosRuiz | in principle it sounds like a big change - hard to implement in core - because the way core is reading the translations | 10:53 |
| norbertbede | i see. that is not good. | 10:53 |
| CarlosRuiz | I'm not very fond about allowing translations per role/user (but that can be done in window customization actually) | 10:53 |
| CarlosRuiz | because that creates some problems for support | 10:53 |
| CarlosRuiz | different users calling to report a problem with a field with different names | 10:54 |
| CarlosRuiz | but anyways | 10:54 |
| CarlosRuiz | what I'm wondering is | 10:54 |
| CarlosRuiz | if in core we could make all the _Trl tables open for tenant records | 10:55 |
| CarlosRuiz | just a draft idea - but maybe that change would be easier to implement | 10:56 |
| CarlosRuiz | for example | 10:56 |
| CarlosRuiz | at this moment | 10:56 |
| CarlosRuiz | AD_Element_Trl has a primary key with AD_Element_ID+AD_Language | 10:56 |
| CarlosRuiz | in my draft idea we would need to change those keys to be (AD_Element_ID+AD_Client_ID+AD_Language) | 10:57 |
| CarlosRuiz | or even adding AD_Org_ID if that's your intention | 10:57 |
| CarlosRuiz | and open some window to allow maintenance in tenant for that table | 10:58 |
| norbertbede | yes. looks same just simplified way | 10:58 |
| CarlosRuiz | and then - we need to look for every query in core for table AD_Element_Trl and add proper filters: | 10:59 |
| CarlosRuiz | WHERE AD_Client_ID IN (0, #AD_Client_ID) | 10:59 |
| CarlosRuiz | ORDER BY AD_Client_ID DESC | 10:59 |
| CarlosRuiz | something like that | 10:59 |
| CarlosRuiz | doesn't sound easy - but sounds easier than your proposal | 11:00 |
| norbertbede | does this candidate for core or customisation | 11:00 |
| CarlosRuiz | that touches a lot of the core - I think cannot be done in customization | 11:00 |
| norbertbede | can you estimate effort/price ? looks we need this. depends on price we decide. | 11:04 |
| norbertbede | maybe in private | 11:08 |
| CarlosRuiz | OK ... let me check it and will write you | 11:16 |
| norbertbede | thanks bb | 11:18 |
| *** muriloht <muriloht!b1346902@gateway/web/freenode/ip.177.52.105.2> has joined #idempiere | 11:40 | |
| *** a42niem <a42niem!~niem@p578b7daf.dip0.t-ipconnect.de> has quit IRC | 13:40 | |
| *** a42niem <a42niem!~niem@p578b7daf.dip0.t-ipconnect.de> has joined #idempiere | 13:52 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has quit IRC | 15:12 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has joined #idempiere | 15:12 | |
| *** norbertbede <norbertbede!~Adium@94.228.89.101> has quit IRC | 16:06 | |
| *** nmicoud <nmicoud!~Nicolas@riv38-2-78-235-108-177.fbx.proxad.net> has quit IRC | 17:25 | |
| Not | [iDempiere] 1 commit to release-6.2 [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/ | 19:20 |
| Not | [iDempiere] globalqss 2e339e8 - Fix oracle datapump scripts | 19:20 |
| Not | [iDempiere6.2] jenkins build #122 started http://ci.idempiere.org/job/iDempiere6.2/122/ | 19:50 |
| Not | [iDempiere6.2] jenkins build #122 completed: success http://ci.idempiere.org/job/iDempiere6.2/122/ | 19:58 |
| *** CarlosRuiz <CarlosRuiz!~CarlosRui@aftr-37-201-194-235.unity-media.net> has quit IRC | 21:04 | |
| *** a42niem <a42niem!~niem@p578b7daf.dip0.t-ipconnect.de> has quit IRC | 22:31 | |
| *** muriloht <muriloht!b1346902@gateway/web/freenode/ip.177.52.105.2> has quit IRC | 22:53 | |
| *** muriloht <muriloht!c8a19c33@gateway/web/freenode/ip.200.161.156.51> has joined #idempiere | 23:28 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!