#idempiere IRC log for Wednesday, 2015-01-28

« Tuesday, 2015-01-27 Index Thursday, 2015-01-29 »
*** fabiocanella has quit IRC00:04
*** norbertbede has quit IRC00:32
*** is-mw2 has joined #idempiere02:04
*** is-mw has quit IRC02:05
*** is-mw has joined #idempiere03:01
*** is-mw2 has quit IRC03:03
*** red1 has joined #idempiere03:56
*** hieplq has quit IRC03:58
*** ChanServ sets mode: +o red104:35
*** jmpiloq_ has quit IRC04:36
*** red1 has quit IRC06:14
*** fabiocanella has joined #idempiere06:34
*** red1 has joined #idempiere07:10
*** ChanServ sets mode: +o red107:10
*** binario01 has joined #idempiere07:13
*** binario01 has left #idempiere07:16
*** norbertbede has joined #idempiere07:21
*** nmicoud has joined #idempiere07:53
*** norbertbede has quit IRC08:19
*** norbertbede has joined #idempiere08:42
*** KermitTheFragger has joined #idempiere08:50
*** CarlosRuiz has quit IRC08:51
*** norbertbede has quit IRC09:10
*** norbertbede has joined #idempiere09:11
*** red1 has quit IRC09:12
*** norbertbede has quit IRC09:21
*** red1_ has joined #idempiere10:51
*** ChanServ sets mode: +o red1_11:42
*** red1_ has quit IRC12:01
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-2235 Attachment set to "IDEMPIERE-2235.patch"12:42
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223512:42
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-2235 labels set to "+Patch"12:42
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223512:42
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-2235 status set to "Peer Review Queue"12:42
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223512:42
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-2235 assignee set to "Carlos Antonio Ruiz Gomez"12:42
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223512:42
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-223512:43
Not-ae23[IDEMPIERE] Please review this patch. Note that i was not able to update the tab title using the setTitle method :-/ I probably miss something. Regards, Nicolas12:43
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223512:43
*** CarlosRuiz has joined #idempiere13:02
*** ChanServ sets mode: +o CarlosRuiz13:02
CarlosRuizGood morning13:02
nmicoudHi Carlos13:02
nmicoudAny chance you can review those following tickets : 2224, 2411, 2235 ?13:03
CarlosRuizok, I'll try to review them today13:08
nmicoudthanks13:08
*** aguerra has joined #idempiere13:16
aguerraBuenos dias13:16
*** hieplq has joined #idempiere13:19
CarlosRuizHi Alejandro13:19
*** is-mw has quit IRC13:40
*** is-mw has joined #idempiere13:40
*** a42niem has joined #idempiere13:41
*** is-mw2 has joined #idempiere13:50
*** is-mw has quit IRC13:53
Not-ae23[iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/14:20
Not-ae23[iDempiere] globalqss 1e89e66 - IDEMPIERE-386 IDEMPIERE-1770 minor - drop unused code and improve order by14:20
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2421 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Cannot Reproduce"14:22
Not-ae23[IDEMPIERE] [~fabiocanella], I was not able to reproduce the issue. Looking at the code maybe you have duplicates in your M_StorageOnHand table. If you find a case able to be reproduced please reopen the ticket with steps to reproduce. Regards, Carlos Ruiz14:22
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242114:22
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-224415:06
Not-ae23[IDEMPIERE] [~nmicoud] have you tested this patch? [~hieplq], the patch refers to a new class RequestEMailProcessorNew which is not referenced in the AD_Process record.15:06
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-224415:06
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-224415:09
Not-ae23[IDEMPIERE] Yes, i've tested it. AFAIR, Hiep write a new java class for testing purpose. The 'old' one should be deleted and RequestEMailProcessorNew renamed as RequestEMailProcessor Nicolas15:09
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-224415:09
Not-ae23[IDEMPIERE] hieplq updated IDEMPIERE-224415:09
Not-ae23[IDEMPIERE] [~carlosruiz_globalqss] RequestEMailProcessorNew will replace RequestEMailProcessor in AD_Process. must manual change it.15:09
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-224415:09
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2244 Attachment set to "IDEMPIERE-2244_req.patch"15:26
Not-ae23[IDEMPIERE] I'm attaching the patch migrated to RequestEMailProcessor, can you please test IDEMPIERE-2244_req.patch I see there is a new parameter to the process with name "p_nestInbox" - but no migration script to create it. Also I see an old hardcoded value (since original version) for "postmaster@CONSULTDESK" - I don't remember the purpose of such verification, but seems unnecessary at this moment, we could drop it.15:26
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-224415:26
aguerrahi Carlos15:31
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-211215:37
Not-ae23[IDEMPIERE] agree [~hieplq], better if esc close just one window15:37
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-211215:37
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-241915:44
Not-ae23[IDEMPIERE] Hi [~hieplq], I think this issue is just for r3? If yes, I think is a blocker as indeed there are big reports in any installation, and we need to try to create a reproducible test case and fix it asap for r3 stabilization.15:44
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-241915:44
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-242015:45
Not-ae23[IDEMPIERE] I've been hit by this same jetty exception - but was not reproducible when I retried. Great if we could find a reproducible test case.15:45
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242015:45
*** KermitTheFragger has quit IRC15:49
Not-ae23[IDEMPIERE] hieplq updated IDEMPIERE-241915:51
Not-ae23[IDEMPIERE] now, i will test it in 2.1 and report late. i can provide my data to test it (at private channel).15:51
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-241915:51
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-241915:55
Not-ae23[IDEMPIERE] sometimes I use to create a view for testing purposes, for example this query returns 39.627.025 rows: select e1.* from ad_element e1, ad_element e215:55
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-241915:55
*** aguerra has quit IRC16:24
*** hieplq_ has joined #idempiere16:39
*** hieplq has quit IRC16:39
Not-ae23[IDEMPIERE] fabiocanella updated IDEMPIERE-242116:43
Not-ae23[IDEMPIERE] Thanks Carlos, as you said there are many "duplicates" rows in M_StorageOnHand table: same M_LOCATOR_ID, M_PRODUCT_ID and M_ATTRIBUTESETINSTANCE_ID value but different DATEMATERIALPOLICY value is not correct ? what you mean by duplicates rows ? Best Regards, Fabio16:43
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242116:43
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-242116:45
Not-ae23[IDEMPIERE] according to the code, there must be two records maybe with same locator, product, asi and date16:45
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242116:45
CarlosRuizHi fabiocanella16:59
fabiocanellaHi 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, right17:00
fabiocanella?17:00
CarlosRuizyep17:01
CarlosRuizwhat I reviewed is:  the MInventory.java in line 65817:02
CarlosRuizcalls17:02
CarlosRuizMStorageOnHand[] storages = MStorageOnHand.getWarehouse ...17:02
CarlosRuizthat gets the records on the locator/product - so you can have several asi and date17:02
CarlosRuizand then for each storage it inserts one MInventoryLineMA17:03
fabiocanellaok17:03
CarlosRuizusing the asi and date17:03
CarlosRuizso, what I understand is that in principle is not possible to insert duplicates - but maybe I'm reading wrong17:04
CarlosRuizhard to debug without a broken test case17:04
fabiocanellaok, I understand... the DateMaterialPolicy if use only for FIFO/LIFO ?17:09
CarlosRuizyes17:10
CarlosRuizold adempiere used to create one storage record for each ASI17:12
CarlosRuizeven when there was no really ASI17:13
CarlosRuizin idempiere we changed that to create one storage record for each date when there is no ASI17:13
fabiocanellayes I read this in the link you send me, ok now I understand better I try to debug, thanks17:14
Not-ae23[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2224 Attachment set to "IDEMPIERE-2224_CR.patch"17:32
Not-ae23[IDEMPIERE] [~nmicoud], I found a simpler patch with the same results, attached as IDEMPIERE-2224_CR.patch But, my concern about this (same on your patch) is that it's too expensive, it's creating a PO object on any DataStatusEvent, and there are many. If you set a breakpoint on GridTable.getPO you'll see how many PO objects are created on each event. IMHO this cost is prohibitive and we would need to find a lighter approach.17:32
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-222417:32
CarlosRuizyw17:32
nmicoudCarlosRuiz : 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 :)17:37
CarlosRuizmaybe you can try to implement formatting on Env.parseContext17:38
nmicoudalready try that. and need PO17:39
CarlosRuizI 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 datatype17:39
nmicoudhum...17:41
nmicoudwill try this17:41
CarlosRuizanother possibility could be17:44
CarlosRuizover the patch we're working - restrict the DataStatusEvents where the getPO is called17:44
CarlosRuizat 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 cases17:45
nmicoudand 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 ?17:46
CarlosRuizalso noticed that Env.parseVariable manages format, but not default - and parseContext manages default but not format - it would be good to unify both approaches17:47
CarlosRuizit could be possible to manage in both cases @variable<format>:default@17:48
nmicoudyes, seems necessary17:48
CarlosRuizbut would need to solve the datatype resolution on Env.parseContext - not easy as you just have the WindowNo17:48
nmicoudand a new syntax @variable<format><datatype>:default@ ?17:50
CarlosRuizah - that sounds interesting17:51
nmicoudugly, but it should work :)17:52
CarlosRuizeasier and it will avoid the cost of resolving the datatype from dictionary17:52
nmicoudyep17:53
CarlosRuizI 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 parseVariable17:53
CarlosRuizthat will solve your issue too, right - no need for the PO for the title logic if we implement such thing17:54
nmicoudyes17:54
nmicoudinteresting !17:54
nmicoudwill update the ticket with this discussion and try to do it17:59
Not-ae23[IDEMPIERE] nmicoud updated IDEMPIERE-222417:59
Not-ae23[IDEMPIERE] IRC [18:37] <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 :) [18:38] <@CarlosRuiz> maybe you can try to implement formatting on Env.parseContext [18:39] <nmicoud> already try t17:59
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-222417:59
fabiocanellaI 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 key18:09
CarlosRuizyep - in the postgres seed there is no _key - just the _pkey18:10
CarlosRuizmigrated?18:10
fabiocanellaproblably... I don't know18:12
*** jmpiloq_ has joined #idempiere18:12
*** aguerra has joined #idempiere18:26
Not-ae23[IDEMPIERE] fabiocanella updated IDEMPIERE-242118:31
Not-ae23[IDEMPIERE] I found the solution: there was an old key M_INOUTLINEMA_KEY that is wrong, the new key is M_INOUTLINEMA_PKEY I deleted the old one and now it seem ok this was probably a migration error18:31
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242118:31
*** norbertbede has joined #idempiere18:37
*** fabiocanella has quit IRC19:43
*** binario01 has joined #idempiere20:15
*** binario01 has left #idempiere20:15
*** a42niem has quit IRC20:53
norbertbedeHI CarlosRuiz21:36
norbertbedei found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-242021:36
CarlosRuizHi norbertbede21:36
norbertbedewhen i click to Feedback>>Email to Support mentioned error log appear and session hangup21:37
norbertbedeafter close tab and login again system works well21:39
norbertbedehope help21:39
Not-ae23[IDEMPIERE] norbert.bede updated IDEMPIERE-242021:41
Not-ae23[IDEMPIERE] when i click to Feedback>>Email to Support mentioned error log appear and session hangup. After close tab and login again system works well. 22:32:18.359-----------> HttpParser.parseNext: badMessage: java.lang.IllegalStateException: too much data after closed for HttpChannelOverHttp@76863770{r=1,c=false,a=IDLE,uri=-} [31]21:41
Not-ae23[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242021:41
CarlosRuizah yes - that was the case where it thrown that error to me - using the support button - didn't remember21:46
*** Edwin_Ang has joined #idempiere22:10
Edwin_Anghi22:11
Edwin_Anganyone here?22:11
CarlosRuizHi Edwin_Ang22:11
Edwin_AngHi Carlos22:11
Edwin_Angcan I ask a simple question?22:11
Edwin_Angi tried the development branch and I can't seem to change the logging level for jetty22:12
CarlosRuizyou just did  :-)22:12
Edwin_Ang:D22:12
Edwin_Angthe DEBUG msg are really annoying22:12
CarlosRuizah - I think hiep raised that in forums - but don't remember if he get any answer22:13
Edwin_Angi tried various method suggested in the jetty docs22:14
Edwin_Angbut none working atm22:14
*** Edwin_Ang has quit IRC22:52
*** nmicoud has quit IRC23:06
« Tuesday, 2015-01-27 Index Thursday, 2015-01-29 »

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!