Difference between revisions of "IDempiere/FullMeeting20150128"
CarlosRuiz (talk | contribs) (full meeting) |
CarlosRuiz (talk | contribs) (drop JIRA notifications from log) |
||
Line 14: | Line 14: | ||
'''''aguerra''''': Buenos dias<br> | '''''aguerra''''': Buenos dias<br> | ||
'''''CarlosRuiz''''': Hi Alejandro<br> | '''''CarlosRuiz''''': Hi Alejandro<br> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
'''''aguerra''''': hi Carlos<br> | '''''aguerra''''': hi Carlos<br> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
'''''CarlosRuiz''''': Hi fabiocanella <br> | '''''CarlosRuiz''''': Hi fabiocanella <br> | ||
'''''fabiocanella''''': Hi Carlos regarding the issue in table IDEMPIERE-2421 I don't know how M_StorageOnHand work: I see that there is M_STORAGEONHAND_PKEY so can't be 2 rows with the same locator, product, asi and date, right<br> | '''''fabiocanella''''': Hi Carlos regarding the issue in table IDEMPIERE-2421 I don't know how M_StorageOnHand work: I see that there is M_STORAGEONHAND_PKEY so can't be 2 rows with the same locator, product, asi and date, right<br> | ||
Line 72: | Line 34: | ||
'''''CarlosRuiz''''': in idempiere we changed that to create one storage record for each date when there is no ASI<br> | '''''CarlosRuiz''''': in idempiere we changed that to create one storage record for each date when there is no ASI<br> | ||
'''''fabiocanella''''': yes I read this in the link you send me, ok now I understand better I try to debug, thanks<br> | '''''fabiocanella''''': yes I read this in the link you send me, ok now I understand better I try to debug, thanks<br> | ||
− | |||
− | |||
− | |||
'''''CarlosRuiz''''': yw<br> | '''''CarlosRuiz''''': yw<br> | ||
'''''nmicoud''''': CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it :)<br> | '''''nmicoud''''': CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it :)<br> | ||
Line 100: | Line 59: | ||
'''''nmicoud''''': interesting !<br> | '''''nmicoud''''': interesting !<br> | ||
'''''nmicoud''''': will update the ticket with this discussion and try to do it<br> | '''''nmicoud''''': will update the ticket with this discussion and try to do it<br> | ||
− | |||
− | |||
− | |||
'''''fabiocanella''''': I think i found the problem: in the database there is a M_INVENTORY_KEY index and also M_INVENTORY_PKEY, problably the KEY (without P) is the old unique key<br> | '''''fabiocanella''''': I think i found the problem: in the database there is a M_INVENTORY_KEY index and also M_INVENTORY_PKEY, problably the KEY (without P) is the old unique key<br> | ||
'''''CarlosRuiz''''': yep - in the postgres seed there is no _key - just the _pkey<br> | '''''CarlosRuiz''''': yep - in the postgres seed there is no _key - just the _pkey<br> | ||
'''''CarlosRuiz''''': migrated?<br> | '''''CarlosRuiz''''': migrated?<br> | ||
'''''fabiocanella''''': problably... I don't know<br> | '''''fabiocanella''''': problably... I don't know<br> | ||
− | |||
− | |||
− | |||
'''''norbertbede''''': HI CarlosRuiz<br> | '''''norbertbede''''': HI CarlosRuiz<br> | ||
'''''norbertbede''''': i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420<br> | '''''norbertbede''''': i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420<br> | ||
Line 116: | Line 69: | ||
'''''norbertbede''''': after close tab and login again system works well<br> | '''''norbertbede''''': after close tab and login again system works well<br> | ||
'''''norbertbede''''': hope help<br> | '''''norbertbede''''': hope help<br> | ||
− | |||
− | |||
− | |||
'''''CarlosRuiz''''': ah yes - that was the case where it thrown that error to me - using the support button - didn't remember<br> | '''''CarlosRuiz''''': ah yes - that was the case where it thrown that error to me - using the support button - didn't remember<br> | ||
'''''Edwin_Ang''''': hi<br> | '''''Edwin_Ang''''': hi<br> |
Latest revision as of 08:58, 29 January 2015
⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2015-01-28
CarlosRuiz: Good morning
nmicoud: Hi Carlos
nmicoud: Any chance you can review those following tickets : 2224, 2411, 2235 ?
CarlosRuiz: ok, I'll try to review them today
nmicoud: thanks
aguerra: Buenos dias
CarlosRuiz: Hi Alejandro
aguerra: hi Carlos
CarlosRuiz: Hi fabiocanella
fabiocanella: Hi Carlos regarding the issue in table IDEMPIERE-2421 I don't know how M_StorageOnHand work: I see that there is M_STORAGEONHAND_PKEY so can't be 2 rows with the same locator, product, asi and date, right
fabiocanella: ?
CarlosRuiz: yep
CarlosRuiz: what I reviewed is: the MInventory.java in line 658
CarlosRuiz: calls
CarlosRuiz: MStorageOnHand[] storages = MStorageOnHand.getWarehouse ...
CarlosRuiz: that gets the records on the locator/product - so you can have several asi and date
CarlosRuiz: and then for each storage it inserts one MInventoryLineMA
fabiocanella: ok
CarlosRuiz: using the asi and date
CarlosRuiz: so, what I understand is that in principle is not possible to insert duplicates - but maybe I'm reading wrong
CarlosRuiz: hard to debug without a broken test case
fabiocanella: ok, I understand... the DateMaterialPolicy if use only for FIFO/LIFO ?
CarlosRuiz: yes
CarlosRuiz: old adempiere used to create one storage record for each ASI
CarlosRuiz: even when there was no really ASI
CarlosRuiz: in idempiere we changed that to create one storage record for each date when there is no ASI
fabiocanella: yes I read this in the link you send me, ok now I understand better I try to debug, thanks
CarlosRuiz: yw
nmicoud: CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it :)
CarlosRuiz: maybe you can try to implement formatting on Env.parseContext
nmicoud: already try that. and need PO
CarlosRuiz: I tried and got stuck because Env.parseContext manages Strings - maybe you could discover the datatype of the column and use number / date or messageformat according to the datatype
nmicoud: hum...
nmicoud: will try this
CarlosRuiz: another possibility could be
CarlosRuiz: over the patch we're working - restrict the DataStatusEvents where the getPO is called
CarlosRuiz: at this moment is called every time - but maybe we can call it just when opening the window - navigating and saving - one time per each - I see sometimes the DataStatusEvent is passed twice on some cases
nmicoud: and what about adding a new event "refresh window title", which could be called only when a title logic is defined and after previous, next, save ?
CarlosRuiz: also noticed that Env.parseVariable manages format, but not default - and parseContext manages default but not format - it would be good to unify both approaches
CarlosRuiz: it could be possible to manage in both cases @variable<format>:default@
nmicoud: yes, seems necessary
CarlosRuiz: but would need to solve the datatype resolution on Env.parseContext - not easy as you just have the WindowNo
nmicoud: and a new syntax @variable<format><datatype>:default@ ?
CarlosRuiz: ah - that sounds interesting
nmicoud: ugly, but it should work :)
CarlosRuiz: easier and it will avoid the cost of resolving the datatype from dictionary
nmicoud: yep
CarlosRuiz: I think it can be good to implement a variable resolver - that parses such thing (variable/format/datatype/default) and we call it from both parseContext and parseVariable
CarlosRuiz: that will solve your issue too, right - no need for the PO for the title logic if we implement such thing
nmicoud: yes
nmicoud: interesting !
nmicoud: will update the ticket with this discussion and try to do it
fabiocanella: I think i found the problem: in the database there is a M_INVENTORY_KEY index and also M_INVENTORY_PKEY, problably the KEY (without P) is the old unique key
CarlosRuiz: yep - in the postgres seed there is no _key - just the _pkey
CarlosRuiz: migrated?
fabiocanella: problably... I don't know
norbertbede: HI CarlosRuiz
norbertbede: i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420
CarlosRuiz: Hi norbertbede
norbertbede: when i click to Feedback>>Email to Support mentioned error log appear and session hangup
norbertbede: after close tab and login again system works well
norbertbede: hope help
CarlosRuiz: ah yes - that was the case where it thrown that error to me - using the support button - didn't remember
Edwin_Ang: hi
Edwin_Ang: anyone here?
CarlosRuiz: Hi Edwin_Ang
Edwin_Ang: Hi Carlos
Edwin_Ang: can I ask a simple question?
Edwin_Ang: i tried the development branch and I can't seem to change the logging level for jetty
CarlosRuiz: you just did :-)
Edwin_Ang: :D
Edwin_Ang: the DEBUG msg are really annoying
CarlosRuiz: ah - I think hiep raised that in forums - but don't remember if he get any answer
Edwin_Ang: i tried various method suggested in the jetty docs
Edwin_Ang: but none working atm