#idempiere IRC log for Friday, 2015-10-30

« Thursday, 2015-10-29 Index Saturday, 2015-10-31 »
Not-33c0[iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/00:35
Not-33c0[iDempiere] globalqss 60c35c7 - IDEMPIERE-2811 Each Record should have a primary key - M_ProductPrice / tested in a real migration with 300K records and it was extremely slow, changed the scripts for speed00:35
Not-33c0[iDempiere] jenkins built #1771 completed (success) http://ci.idempiere.org/job/iDempiere/1771/00:46
*** CarlosRuiz has quit IRC03:59
Not-33c0[iDempiereDaily] jenkins built #467 completed (success) http://ci.idempiere.org/job/iDempiereDaily/467/04:08
*** mbozem has joined #idempiere06:09
*** nmicoud has joined #idempiere06:46
*** a42niem has joined #idempiere06:53
*** KermitTheFragger has joined #idempiere07:31
*** mbozem has quit IRC07:56
Not-33c0[IDEMPIERE] chaianan created IDEMPIERE-2920 Production Control07:57
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-292007:57
*** mbozem has joined #idempiere08:17
*** Werner_ has joined #idempiere10:33
*** hieplq has joined #idempiere12:06
*** CarlosRuiz has joined #idempiere12:33
*** ChanServ sets mode: +o CarlosRuiz12:33
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2920 status set to "Resolved" -resolution set to "Incomplete"12:40
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-292012:40
*** nmicoud has quit IRC13:00
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2919 priority set to "Minor"13:13
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291913:13
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2919 Component set to "Zk Web Client"13:13
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291913:13
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2919 labels set to "infowindow"13:13
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291913:13
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2919 labels set to "Triaged infowindow"13:13
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291913:13
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2919 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed"14:17
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291914:17
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-223014:18
Not-33c0[IDEMPIERE] After review if IDEMPIERE-2919 I noticed that this won't work if enabled multi-selection on an InfoWindow like business partner where there can be multiple lines with the same BP Key. It works fine with InfoProduct because each line is a different product.14:18
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-223014:18
Not-33c0[iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/14:18
Not-33c0[iDempiere] globalqss ccd1766 - IDEMPIERE-2919 InfoBP don't take the first contact / IDEMPIERE-223014:18
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-279814:22
Not-33c0[IDEMPIERE] Hi [~cboecking], I think this is intentional, your solution can bring issues, I remember using the lowercase "where" in some special cases to avoid wrong parsing.14:22
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279814:22
Not-33c0[iDempiere] jenkins built #1772 completed (success) http://ci.idempiere.org/job/iDempiere/1772/14:26
*** nmicoud has joined #idempiere14:45
*** KermitTheFragger has quit IRC16:30
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-242316:37
Not-33c0[IDEMPIERE] Made a test today and the reservations of both products go wrong. Test case: - Create a Standard SO for product Seeder, complete - Create the Shipment for the SO, on Sales Order line change the producto to Weeder, complete At the end the reservation for Seeder is 1, for Weeder is -116:37
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-242316:37
hieplqhi mr CarlosRuiz, i has new patch for "update.sh run with issue", it will fix NPE message. please review it16:39
CarlosRuizyep - hieplq - saw it - I'm not sure if that's a good idea - asked hengsin about16:41
*** mbozem has quit IRC17:09
*** hieplq has quit IRC17:15
*** CarlosRuiz has quit IRC18:40
*** nmicoud has quit IRC19:09
Not-33c0[IDEMPIERE] cboecking updated IDEMPIERE-279821:52
Not-33c0[IDEMPIERE] [~carlosruiz_globalqss], is this because the system is expecting users to enter SQL key terms in upper case? That is the only time that I can think of that would cause an issue.21:52
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279821:52
*** CarlosRuiz has joined #idempiere22:43
*** ChanServ sets mode: +o CarlosRuiz22:43
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-279822:53
Not-33c0[IDEMPIERE] [~cboecking], users do not enter SQL, it's a tool for developers or for implementors that configure i.e. Info Windows or other SQL related stuff. In some cases when writing complex SQL, like with many embedded queries the MRole.addAccessSQL fails because it cannot parse properly the SQL, one possibility would be to write a more complex parser - another possibility is to write a way to bypass the finding22:53
Not-33c0of the "WHERE" - I think the second was the choice from JJ.22:53
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279822:53
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-279822:58
Not-33c0[IDEMPIERE] As an example of the "bypass" you can check this thread: https://groups.google.com/d/msg/idempiere/QNo2VukHDBM/8j0059Ikj-kJ22:58
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279822:58
Not-33c0[IDEMPIERE] cboecking updated IDEMPIERE-279823:02
Not-33c0[IDEMPIERE] [~carlosruiz_globalqss] - so I think your answer is yes (at least sometimes) to " is this because the system is expecting -users- admins to enter SQL key terms in upper case?". And yes - this is a bug. And yes - the issue goes much deeper that this ticket represents. Therefore, I guess we can close this ticket as unresolved unless someone wants to deep dive and fix it.23:02
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279823:02
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-291023:02
Not-33c0[IDEMPIERE] [~hieplq], this is the comment from [~hengsin] about the patch: {quote} it is better to specify the version you would like to get from the server. This help to avoid a partial update of framework to 4.4.3 in future materialization. {quote}23:02
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-291023:02
*** mbozem has joined #idempiere23:08
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-279823:28
Not-33c0[IDEMPIERE] I think is not a bug, it is a feature, and consequently the ticket closure must be "Won't fix" or "Incomplete" :-)23:28
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279823:28
Not-33c0[IDEMPIERE] cboecking updated IDEMPIERE-279823:39
Not-33c0[IDEMPIERE] I think the ability to type in a "WHERE" statement to bypass the MRole.addAccessSQL is a feature. That is pretty cool - I did not know that. Having the result end up in a malformed SQL statement like stated in the description (see bold text) is a bug. It causes the system to fail due to a SQL exception.23:39
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279823:39
Not-33c0[IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-279823:44
Not-33c0[IDEMPIERE] I would say that's a misconfiguration - if you configure it properly then it works - if you configure it wrongly then it doesn't work. I think the most prominent issue here is that this is an undocumented feature - you could consider it a "documentation bug" better.23:44
Not-33c0[IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-279823:44
*** mbozem has quit IRC23:50
« Thursday, 2015-10-29 Index Saturday, 2015-10-31 »

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