*** mbozem has joined #idempiere | 02:34 | |
*** a42niem has joined #idempiere | 06:20 | |
*** mbozem has quit IRC | 06:35 | |
Not-33c0 | [IDEMPIERE] tsvikruha updated IDEMPIERE-2230 | 06:50 |
---|---|---|
Not-33c0 | [IDEMPIERE] [~carlosruiz_globalqss] that's the case why we needed ViewID (IDEMPIERE-1970). This could be used also in this case but question is how? I also met something similar while testing IDEMPIERE-2709. | 06:51 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2230 | 06:51 |
*** mbozem has joined #idempiere | 07:17 | |
*** KermitTheFragger has joined #idempiere | 07:32 | |
*** BizU has joined #idempiere | 08:43 | |
BizU | hi all, let me to discuss idmepiere | 08:44 |
*** nmicoud has joined #idempiere | 09:11 | |
*** nmicoud has quit IRC | 10:17 | |
*** mbozem has quit IRC | 10:33 | |
*** nmicoud has joined #idempiere | 10:35 | |
*** hieplq has joined #idempiere | 10:51 | |
*** mbozem has joined #idempiere | 10:57 | |
*** nmicoud has quit IRC | 11:08 | |
*** a42niem has quit IRC | 11:14 | |
*** hieplq has quit IRC | 11:22 | |
*** hieplq has joined #idempiere | 11:24 | |
Not-33c0 | [IDEMPIERE] hieplq updated IDEMPIERE-2907 status set to "Reopened" -resolution set to "None" | 11:28 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2907 | 11:28 |
Not-33c0 | [IDEMPIERE] hieplq updated IDEMPIERE-2907 Attachment set to "IDEMPIERE-2907-MF.patch" | 11:28 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2907 | 11:28 |
Not-33c0 | [IDEMPIERE] hieplq updated IDEMPIERE-2907 | 11:31 |
Not-33c0 | [IDEMPIERE] [^IDEMPIERE-2907-MF.patch] is patch for below warning in eclipse or build by headless "Version '7.0.7.qualifier' of plug-in 'org.zkoss.zk.library' is not available." | 11:31 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2907 | 11:31 |
Not-33c0 | [IDEMPIERE] hieplq updated IDEMPIERE-2907 status set to "Peer Review Queue" | 11:31 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2907 | 11:31 |
*** a42niem_ has joined #idempiere | 12:10 | |
*** hieplq has quit IRC | 13:26 | |
*** hieplq has joined #idempiere | 13:27 | |
*** CarlosRuiz has joined #idempiere | 15:09 | |
*** ChanServ sets mode: +o CarlosRuiz | 15:09 | |
Not-33c0 | [IDEMPIERE] dantam created IDEMPIERE-2921 Restrict service products from being delivered when items are back ordered | 15:09 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2921 | 15:09 |
*** mbozem has quit IRC | 16:31 | |
*** norbertbede has joined #idempiere | 16:35 | |
norbertbede | hi CarlosRuiz | 16:36 |
norbertbede | want to ask a conceptual question | 16:36 |
norbertbede | we need to decide it is important or not for communitz | 16:36 |
norbertbede | we need time to time in warehouses use pricelist fboth for sales and purchase side | 16:36 |
norbertbede | this way we want improve Pricelist from issotrx to list sales/purchase/both | 16:37 |
norbertbede | wdyt | 16:37 |
norbertbede | if no community interest we made customisation | 16:37 |
*** BizU has quit IRC | 16:39 | |
*** hieplq has quit IRC | 16:45 | |
CarlosRuiz | Hi norbertbede - I think that's better to ask in forums | 16:52 |
*** mbozem has joined #idempiere | 16:56 | |
norbertbede | ok thanks | 16:59 |
*** KermitTheFragger has quit IRC | 17:02 | |
CarlosRuiz | I added some time ago the SO/PO/Both list on dictionary - for payment terms I think - so it would be like using that one for price lists - let's see what community think about it | 17:10 |
norbertbede | i created a thread | 17:13 |
norbertbede | well | 17:13 |
norbertbede | thanks anyway | 17:13 |
norbertbede | let me ask one more question | 17:14 |
norbertbede | setup.ini is config where i can add more jvm parameters ? | 17:15 |
norbertbede | cant find wiki for this | 17:15 |
CarlosRuiz | if you start with "idempiere" - I think it read parameters from setup.ini | 17:16 |
CarlosRuiz | but if you start with idempiere.sh you can add the parameters right there | 17:16 |
CarlosRuiz | I usually add them directly on idempiere.sh | 17:16 |
norbertbede | ok thanks | 17:18 |
norbertbede | i bit unconfortable if i have lot jvm parameters in one long line :) | 17:19 |
*** xapiens has joined #idempiere | 17:26 | |
*** mbozem has quit IRC | 17:29 | |
*** xapiens has quit IRC | 17:29 | |
*** a42niem_ has quit IRC | 17:51 | |
*** ChuckBoecking has joined #idempiere | 18:13 | |
ChuckBoecking | Hi Carlos, you have a moment to discuss https://idempiere.atlassian.net/browse/IDEMPIERE-2798 | 18:18 |
ChuckBoecking | I am trying hard to understand. | 18:18 |
ChuckBoecking | Hi CarlosRuiz, you have a moment to discuss https://idempiere.atlassian.net/browse/IDEMPIERE-2798 | 18:26 |
CarlosRuiz | Hi ChuckBoecking | 18:26 |
ChuckBoecking | sorry for the double tab. I did not know if addressing you as Carlos (not CarlosRuiz) would notify you. | 18:27 |
CarlosRuiz | no, just the second | 18:27 |
ChuckBoecking | cool. | 18:27 |
ChuckBoecking | So, reviewed the linked ticket and discussion. I feel like I understand the issue and the fix for that scenario. | 18:27 |
ChuckBoecking | I feel like I undestand the MRole.getAccessSQL() method | 18:28 |
ChuckBoecking | If I read it correctly, the " WHERE " drives whether you add a "where" or "and". I am struggling to see how using "WHERE" phase turns it off. Can you give me a code line hint? | 18:30 |
ChuckBoecking | thank you for your time and patience on this matter | 18:31 |
CarlosRuiz | ChuckBoecking, I don't understand why you see this as an issue :-) | 19:02 |
ChuckBoecking | good question - | 19:03 |
CarlosRuiz | in some cases (like in the link I pointed in forums - virtual column) the MRole.getAccessSQL parses wrongly the SQL and output a wrong one | 19:03 |
ChuckBoecking | A user what trying to limit the results of a window by using the tab's where clause. He could not figure out why it was not working | 19:03 |
CarlosRuiz | that's not a tool for users | 19:04 |
ChuckBoecking | He was in the habit of always using upper case key words | 19:04 |
ChuckBoecking | when I say user, I mean admin. | 19:04 |
CarlosRuiz | ok - then I would expect admins to be a littlemore saviour ;-) | 19:04 |
CarlosRuiz | and I guess admins can expect a better documentation :-) our fault | 19:04 |
ChuckBoecking | that is where I do not understand. I have used the where clause for years. | 19:04 |
CarlosRuiz | so - that's why in the end I see this as a documentation problem | 19:04 |
CarlosRuiz | the workaround in such case is that simple - put where in lowercase when you don't want that part to be touched | 19:05 |
ChuckBoecking | that makes sense | 19:05 |
CarlosRuiz | look here for the real case where that happened | 19:05 |
CarlosRuiz | https://groups.google.com/d/msg/idempiere/QNo2VukHDBM/8j0059Ikj-kJ | 19:05 |
ChuckBoecking | since you said there are times where it does make sense to have an upper case where, I am trying to find that scenario. | 19:05 |
ChuckBoecking | I cannot find one where the system would make any intelligble decision. | 19:06 |
CarlosRuiz | most of the cases I write where in uppercase | 19:06 |
CarlosRuiz | just move to lowercase when the AccessSqlParser is broken | 19:06 |
ChuckBoecking | that - I undestand | 19:06 |
ChuckBoecking | so here is my question... | 19:07 |
ChuckBoecking | Are there other key words (such as FROM, SELECT) what the AD_Tab.WhereClause depends on? | 19:07 |
ChuckBoecking | where case matters... | 19:08 |
CarlosRuiz | I guess there must be - but haven't checked | 19:08 |
ChuckBoecking | Once I started going down the rabbit hole, I was looking for a valid reason have an upper case. | 19:08 |
ChuckBoecking | Especially since the rest of the system like it when you do use upper case for key words. | 19:09 |
CarlosRuiz | my "rule of thumb" is like this -> write reserved words in uppercase everywhere | 19:09 |
CarlosRuiz | test | 19:09 |
CarlosRuiz | if you get the AccessSqlParser.getTableInfo: More than one FROM clause | 19:10 |
CarlosRuiz | then move the offending where to lowercase | 19:10 |
CarlosRuiz | that's my way of coping with that | 19:10 |
ChuckBoecking | :) | 19:10 |
ChuckBoecking | I can deal with that... | 19:10 |
ChuckBoecking | where should I document that wisdom? | 19:10 |
ChuckBoecking | in whereClause AD? | 19:11 |
CarlosRuiz | don't know - maybe a "Tips and Tricks" space - | 19:11 |
ChuckBoecking | OK - I will close the ticket as such. | 19:13 |
CarlosRuiz | :-) JJ coping with similar scenario | 19:13 |
CarlosRuiz | https://sourceforge.net/p/compiere/bugs/2038/ | 19:13 |
CarlosRuiz | funny answer at the end - in the end again -> it's a lack of documentation | 19:14 |
ChuckBoecking | I think what cause the issue is the 'bypass'. I though that you were saying you could by pass it as in turn it off. I now understand that you mean "does not get caught by". | 19:14 |
ChuckBoecking | thanks again for your time and patience :) | 19:15 |
CarlosRuiz | np - gr8 if you can document it somewhere - so next time we just refer people there :-) | 19:16 |
Not-33c0 | [IDEMPIERE] cboecking updated IDEMPIERE-2798 description set to "UPDATE: Closing this ticket as a documentation issue. Here are the comments/advice moving forward: * Generally speaking, admins should use upper case when writing SQL key words. * There are times when iDempiere's is not capable parsing the SQL correctly when admins inject SQL in ColumnSQL or WhereCause fields. This ticket represents an example. Others | 19:47 |
Not-33c0 | are listed below. * You can identify this situation by reviewing the logs and reading the resulting SQL generated by the parser. Error results might include "More than one FROM clause", or you receive a SQLException. * The solution is to make your SQL keywords lowercase, and therefore prevent your clause from being caught in the SQL Parser. ----------------- Original Post ----------------- Using the word "WHERE" in | 19:47 |
Not-33c0 | upper case in the AD_Tab => whereClause field causes a SQL exception because of a poorly formed SQL statement. Here is how to reproduce. Add the following to the Sales Order window's Sales Order Line tab's where clause: C_Order_ID in (Select o.C_Order_ID from C_Order o WHERE o.C_Order_ID = @C_Order_ID@) This will cause a SQL exception. If you make the "WHERE" word lowercase, the all works as expected. The easy | 19:47 |
Not-33c0 | solution is to modify the MTab.getWhereClause() to return a .lower version of the string. If you want to investigate further, set a break point at GridTable line 410 where it executes the MRole.addAccessSQL. Here is an example of the malformed SQL. See the bolded text. SEVERE: Count SQL=SELECT COUNT(*) FROM C_OrderLine WHERE ((C_Order_ID in (Select o.C_Order_ID from C_Order o WHERE o.C_Order_ID = 1000000)) AND | 19:47 |
Not-33c0 | C_OrderLine.C_Order_ID=1000000) AND C_OrderLine.AD_Client_ID IN(0,11) AND C_OrderLine.AD_Org_ID IN(50007,0,50004,50005,50006,50000,50001,50002,11,12) AND (*WHERE.C_OrderLine_ID* IS NULL OR WHERE.C_OrderLine_ID NOT IN ( SELECT Record_ID FROM AD_Private_Access WHERE AD_Table_ID = 260 AND AD_User_ID <> 100 AND IsActive = 'Y' )) Please review. If you agree with my assessment, just let me know and I can make the patch to | 19:47 |
Not-33c0 | make the whereClause getter return lower case. Regards, Chuck Boecking www.chuckboecking.com" | 19:47 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2798 | 19:47 |
Not-33c0 | [IDEMPIERE] cboecking updated IDEMPIERE-2798 status set to "Closed" -assignee set to "Chuck Boecking" -resolution set to "Won't Fix" | 19:49 |
Not-33c0 | [IDEMPIERE] Closing as a documentation issue. | 19:49 |
Not-33c0 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2798 | 19:49 |
*** nmicoud has joined #idempiere | 21:04 | |
*** nmicoud has left #idempiere | 21:11 | |
*** norbertbede has quit IRC | 21:48 | |
*** norbertbede has joined #idempiere | 21:48 | |
*** mbozem has joined #idempiere | 21:49 | |
*** mbozem has quit IRC | 22:06 | |
*** CarlosRuiz has quit IRC | 22:41 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!