Advanced search: Like operator not usable

59 views
Skip to first unread message

reua...@gmail.com

unread,
Jan 18, 2021, 7:51:07 PM1/18/21
to iDempiere
Hello Community,
I just run into a problem with the like operator in the advanced tab of the lookup window:
Unfortunately the search string can only be selected from existing records via dropdown. This way it does not make much sense.
In the Lookup record tab that implicitly uses the like operator there is the option to type a search string including wild cards. That is not possible in the advanced window.  I would love to have that also in the advanced tab. 
NB: I am also missing a is not null entry in the operator dropdown list. I would have needed that today.

Thanks for listening

Andreas


Bildschirmfoto 2021-01-19 um 01.38.46.png

reua...@gmail.com

unread,
Jan 18, 2021, 8:22:18 PM1/18/21
to iDempiere
I have done some more testing and found that the problem seems to be with the synchronization of the column and operator fields. 
It seems that the operator list and the query value editor are not always updated with the new data type when another column has been selected. 
Can anybody confirm that?
Andreas
 

Heng Sin Low

unread,
Jan 18, 2021, 9:04:24 PM1/18/21
to idem...@googlegroups.com
Please try to reproduce the issue at test.idempiere.org. If it is reproducible, create new jira tickets with details and screen capture from test.idempiere.org.

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/baa1dcc2-cc1d-4a6e-985c-b759d0f4f6b2n%40googlegroups.com.

reua...@gmail.com

unread,
Jan 19, 2021, 7:00:38 AM1/19/21
to iDempiere
Thanks Hengsin for pointing me to the Test server.
After beeing unable to confirm the problem there I went back and found the cause in my own installation. 
Note to myself: 
'Better not post an issue to the group before confirming it on the test server.'

Andreas


reua...@gmail.com

unread,
Jan 19, 2021, 3:33:52 PM1/19/21
to iDempiere
It seems i was too fast calling it off. I have now been able to reproduce the behavior on the test server.

The example can be found at test.idempiere.org.
Log in as GardenAdmin and open the Two Tab Test window.
Here the search window will show the behavior I have described in my first post.
Note that the Parent Item column is a number and not a String (Foreign key restraint to the primary key column of the same table.)
The error appears when the stored Parents search preset is called up.

Bildschirmfoto 2021-01-19 um 21.10.30.png

I had actually created the setup to illustrate another quirk and maybe the search window error has something to do with that.
I thought it would be a good idea to have the same table in a parent and a child tab in the same window. 
This way I can display the child items (if present) in the child tab which IMO is actually a useful thing to have.
However this causes another interesting issue:
The key column of the table is accessed through a foreign key from another table column that uses a search reference.
What happens is that the columns are duplicated in the search dialog grid.
Menu > Item Search Test > Two Tab Test > Search Dialog

Bildschirmfoto 2021-01-19 um 21.19.03.png

The Columns are displayed correctly when the child tab is removed from the Two Tab Test window.
I am afraid I have not been able to check wether this also heals the search window issue.

Best regards

Andreas 

Carlos Antonio Ruiz Gomez

unread,
Jan 19, 2021, 4:41:12 PM1/19/21
to idem...@googlegroups.com
Yes, reproducible, is a bug.

Regards,

Carlos Ruiz


El 19/1/21 a las 21:33, reua...@gmail.com escribió:
> It seems i was too fast calling it off. I have now been able to
> reproduce the behavior on the test server.
>
> The example can be found at test.idempiere.org.
> Log in as GardenAdmin and open the Two Tab Test window.
> Here the search window will show the behavior I have described in my
> first post.
> Note that the Parent Item column is a number and not a String (Foreign
> key restraint to the primary key column of the same table.)
> The error appears when the stored Parents search preset is called up.
>
>
>
> I had actually created the setup to illustrate another quirk and maybe
> the search window error has something to do with that.
> I thought it would be a good idea to have the same table in a parent
> and a child tab in the same window.
> This way I can display the child items (if present) in the child tab
> which IMO is actually a useful thing to have.
> However this causes another interesting issue:
> The key column of the table is accessed through a foreign key from
> another table column that uses a search reference.
> What happens is that the columns are duplicated in the search dialog grid.
> Menu > Item Search Test > Two Tab Test > Search Dialog
>
>
>

reua...@gmail.com

unread,
Jan 20, 2021, 6:59:44 AM1/20/21
to iDempiere
I found that the two Bugs are independent from each other. The search tab bug when there is only one tab in the window.
I just have checked that on my own server and at the test server. 
The operator Dropdown entries for a foreign ID column is corrupted when a search preset is loaded in any window's Advanced Search tab.

Steps to reproduce:
test.idempiere.org > Menu > Product > Search > Load BugTest preset

Bildschirmfoto 2021-01-20 um 12.37.29.png

Filing two separate issues.

Andreas

Carlos Antonio Ruiz Gómez

unread,
Jan 20, 2021, 8:50:55 AM1/20/21
to iDempiere
Reply all
Reply to author
Forward
0 new messages