IDempiere/FullMeeting20130710

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2013-07-10

CarlosRuiz: Good morning
nmicoud: Bonjour
hengsin: Hi Carlos
xolali: Halooo
nmicoud: any news on https://idempiere.atlassian.net/browse/IDEMPIERE-959 ?
xolali: concerning wednesday meetimgs, is it usually adhoc or based on agenda
CarlosRuiz: no agenda usually - if you want to discuss something just bring it up :-)
xolali: ok
a42niem: hi Carlos, hi all
CarlosRuiz: Hi Dirk
CarlosRuiz: if hengsin is ok with IDEMPIERE-959 - is fine for me
CarlosRuiz: but I think ProcessInfo patch must be different
CarlosRuiz: you better preserve the old method for backward compatibility
CarlosRuiz: and call the new method with the UUID at the end
nmicoud: ok i'll have a look
hengsin: yeah, should preserved the existing processinfo constructor
nmicoud: then i will update the patch
hengsin: and it should eliminate unnecessary changes like the following - ProcessInfo pi = new ProcessInfo("", 0, MProject.Table_ID, project_id, "");
nmicoud: also, i guess we will have to add methods based on UU on MRefList (eg org.compiere.model.MRefList.getList(Properties, int, boolean) => MRefList.getList(Properties, UUID, boolean)
hengsin: hmm ... actually if you have ad_process_id, you can get ad_process_uu from database. returning ad_process_id > 0 and ad_process_uu = "" from processInfo is rather misleading.
a42niem: working on IDEMPIERE-1120 (Field SeqNo customization) i noticed that IDEMPIERE-163 (isupdateable) had some "side effect" on the callout for WindowCustomization
a42niem: currently the suer gets only minimal informatzion about the current status of the field
hengsin: also, should use MProcess get (Properties ctx, int AD_Process_ID) instead of new MProcess so cache is used
ocurieles_dcs: Hi
CarlosRuiz: Hi Orlando
ocurieles_dcs: Hi Carlos
a42niem: the seqno is empty besides other fields which makes it hard to customize
hengsin: Carlos, for average costing, do you know of any example usage of other cost elements ?
a42niem: i like to put filling this field (and maybe others) back into the callout - WDYT?
CarlosRuiz: hengsin, on the UUID - then maybe is better to have separated constructors? one for the ID (as it was) and one with UUID (without ID as parameter)?
hengsin: I guess the uuid parameter could be unnecessary since ProcessInfo can get it from database. with MProcess.get cache, the overhead should be minimal as well.
CarlosRuiz: but I think maybe the idea is for extensions to be able to get the process using UUID
CarlosRuiz: like WPaySelect is calling process using ID - on extension you need to figure out the ID using the process name or value
CarlosRuiz: which makes the extension dependent on that updatable field - if somebody changes it the extension is broken
CarlosRuiz: ah - but that's not what the ticket is solving
CarlosRuiz: I see - and in such case you can get the ID using the UUID and call the processinfo anyways
hengsin: for that we need MProcess.get(String uuid)
hengsin: but just convenient api, as you mention above, it is trivial to get id from a fixed uuid value.
CarlosRuiz: agree - so, 959 seems adding to much code for something that can be done in a different way without too much work
hengsin: I think MProcess.get(String uuid) with cache should be useful for extension.
ocurieles_dcs: the libero MFG is cutted completely of idempiere ?
CarlosRuiz: a42niem, the idea of IDEMPIERE-163 I think it was that we tried to ensure that all fields on window customization can be nullable - and if they are null then we use the configured on field/column
hengsin: I believe we 've disable most if not all libero MFG related stuff
a42niem: ok, understood - this just makes it hard for the user to know how to change certain column values because the current value is not clear
CarlosRuiz: I think is ok if you want to add it to callout - just be sure that it keeps nullable
CarlosRuiz: also - was thinking how to do this but didn't find a straight way - I think BY DEFAULT window customization must not be assigned to GardenAdmin user
CarlosRuiz: sorry - GardenAdmin role
CarlosRuiz: but added manually
a42niem: why?
CarlosRuiz: but that maybe would mean adding a flag to window/process/form etc -> like IsSecure
CarlosRuiz: security issue
CarlosRuiz: window customization is unsafe in hands of a user - I mean an end user - not the implementor or the IT guy
CarlosRuiz: but people tend to assign initially the admin role to everybody - until they configure the roles
a42niem: sure...
a42niem: so you have to qualify somehow first before being allowed to use it - pass an exam, get some credit points, ...
CarlosRuiz: :-D
a42niem: hm
CarlosRuiz: be trustable
CarlosRuiz: assume responsibility
CarlosRuiz: don't be an internal hacker :-D
a42niem: yesyes
CarlosRuiz: I mean window customization is exposing dictionary management to tenant
CarlosRuiz: if you set the default for c_order.description like @SQL=SELECT password FROM ....
CarlosRuiz: you know what happens
a42niem: hmmmmmm
a42niem: but it is sooo usefull
CarlosRuiz: of course - like pack in - just that you must ensure is in proper hands
CarlosRuiz: hengsin, on the cost question
CarlosRuiz: the usual sample must be freight and customs as different cost elements
CarlosRuiz: but - in a heavy customization environment we did
CarlosRuiz: we eliminated cost element at all :-(
a42niem: as you said: we could attach a flag to it and only unlock such functionality using a hardly documented system configurator entry
CarlosRuiz: and the landing cost is going straight against the cost
CarlosRuiz: ah - good idea! maybe unlock such functionality just to people marked as admin
a42niem: so that only a die hard admin is able to use it
CarlosRuiz: a DisplayLogic for the dangerous fields
a42niem: sort of
ocurieles_dcs: somebody used google graph ?
nmicoud__: for 959, just be sure of modification needed to be done : restore old constructor and add a new one MProcess.get(uuid) - which uses cache. and then remove unneeded modification ?
CarlosRuiz: nmicoud__, seems like you got disconnected on the middle of the discussion
nmicoud__: that's possible
nmicoud__: 2 or 3 times
nmicoud__: if everything was explained, i'll read the minutes
CarlosRuiz: ok - I'll publish it as soon as we finish
nmicoud__: no need to hurry ; i won't do it until tomorrow
CarlosRuiz: ocurieles_dcs, google charts?
ocurieles_dcs: https://developers.google.com/chart/
ocurieles_dcs: integration would be interesting
CarlosRuiz: looks good for a dashboard
ocurieles_dcs: https://developers.google.com/chart/interactive/docs/gallery
ocurieles_dcs: :-D very nice
CarlosRuiz: I smell an extension? :-D
xolali: Lol
CarlosRuiz: https://code.google.com/p/zk-sample-code/source/browse/trunk/WebContent/samples/sam/chart/googleChart.zul
ocurieles_dcs: yes..
ocurieles_dcs: cooming soon
hengsin: the only problem is then you are at google's mercy
ocurieles_dcs: Thanks to @hengsin for the recommendations, we are working in the changes
hengsin: carlos, yeah, I guess the easiest is to just add the landed cost to the product average cost. the problem with landed cost element is you must make sure their currentqty exactly match with the average cost's current qty
hengsin: considering whether I should just take the easy route to fix the current landed cost allocation :)
CarlosRuiz: I don't know why the landed cost was done that way - is assigned to an element and increasing the COGS on each posting - but doesn't have qty control
hengsin: ocurieles_dcs, feel free to let me know if any of my comments doesn't work well or completely insane.
CarlosRuiz: and trying to control qty of landed cost is messy - you can have a landed cost qty <> than inventory qty - so you need to control when the landed cost is exhausted
CarlosRuiz: even you can have the qtys negative in some cases
hengsin: Carlos, basically, you just have to make the two exactly the same. it wouldn't work otherwise
CarlosRuiz: what I found better was to set the landed cost directly to cost - that implied a lot of changes
xolali: ocurieles_dcs: whilst you are at it, u can also check http://www.highcharts.com/
hengsin: Carlos, I don't see that need lots of changes.
CarlosRuiz: and there is a problem when you receive a landed cost but don't have inventory - you need to manage that different - I mean - or postpone the landed cost until you have inventory - or send it to expenses
ocurieles_dcs: ok xiali, i will check
hengsin: you can captured that as average cost variance or it can goes straight to cogs
xolali: its integrated into ZK, i just saw http://zhighcharts.appspot.com/
hengsin: that's the common treatment - have done some research on that today :)
CarlosRuiz: you're right - not lot of changes - but small changes on different locations
hengsin: the key implication is now you don't the m_cost record for landed cost element.
hengsin: whatever that means :)
CarlosRuiz: yes - thinking if we need an historic for that - or it is already on accounting
hengsin: highchart is not free but that would be a good candidate for extension.
hengsin: http://www.chartjs.org/ - opensource
hengsin: https://github.com/nnnick/Chart.js - any volunteer for this :)
ocurieles_dcs: let´s my try
xolali: i'll lend a hand too
ocurieles_dcs: ok, this is our repo in bitbucket https://bitbucket.org/dcs_bitbucket
hengsin: another opensource js library - http://www.jqplot.com/
ocurieles_dcs: create a project there
xolali: hengsin my thinking is that we dont adopt a purely html5 library for compatibility with older browsers
xolali: WDYT??
nmicoud__: gtg ; bye bye
hengsin: xolali, I don't think idempiere's zk client is highly compatible with older browser either.
xolali: ok. so html5 it is.