bom.class.php line 394 attempt to compare an integer with a string ?

[slotic]

Bug

[Short description] BOM::fetchAll Error ERROR: 42883: operator does not exist: integer ~~* unknown LINE 1: ...om_bom as t WHERE t.entity IN (1) AND (fk_product ILIKE '%19... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

Environment

• Version: 12.0.1
• OS: Ubuntu 16.04
• Web server: Apache
• PHP: 7.2
• Database: Postgresql
• URL(s): N/A

Expected and actual behavior

[Verbose description] fk_product is an integer, seems that using ILIKE '%value%' is interpreted like a comparison between an integer and a string

Steps to reproduce the behavior

[Verbose description]

Attached files (Screenshots, screencasts, dolibarr.log, debugging informations…)

[Files] 20200801_dolibarr.log

[eldy]

Can you describe how you reproduce the error ?

[slotic]

Hi eldy, thanks for your message

Finally found that the call to fetchall comes from a 'factory' script (pdf joined), line 537 of the php source and first line of the page 10 of the PDF 20200802_index.php.pdf . I've added 3 var_dump. Not sure how to interpret the result.. The first one ($id) which is the compared parameter gives string(3) "198" ... i guess it's the reason why there is a problem in the bom class -> fk_product is an integer, the compared value is a string so it doesn't work

What i don't understand is why id$ is a string because it's declared as an integer on the top of the script but i'm far to be a php guru.. If anyway you think that it's really a problem in the way of the bom class is working please let me know

But i suppose now that

it's not a problem with the bom class but in the patas-monkey's script which sends a wrong type of value to be compared ?

I'm going to try to reach Charlene but it' usually and unfortunately a nightmare to have an answer, even for big bugs easy to correct like double quotes in sql request which are not understood by postgresql but come back every time in new realeases...

Sorry if i bothered you for nothing.. Regards

[slotic]

By the way tested the sql request manually with pgadmin and it works only with 198

Any attempt to use %198% or '%198%' fails.. Does it mean that the class script cannot be used with an integer ?

[slotic]

Works fine if the bom class is lightly modified to handle fk_product correctly lien 384

if ($key == ('t.rowid') OR $key == ('fk_product')) {

So finally is it Charlene who is badly using a call to the bom class with fk_product or is it the bom class which is not yet implemented to handle fk_product like it does for t.rowid ??

Up to you to decide i guess...

[slotic]

Same problème with another script factory/fiche.php line 1099 (PDF joined end of page 19 ) with a sql request for an extraction of active BOMs.. the colums 'status' is an integer and it falls down in the 'else' of the bom class, same problem, same error

20200802_fiche.php.pdf

[dpriskorn]

Please link directly to the line in the file in github if possible.

[dpriskorn]

Who is Charlene? Are you using non core modules?

[slotic]

"Charlene" is the author of the Factory third-party module proposed in Dolistore by Patas-Monkey

Anyway the problem here is definitively that the bom class seems to only deals with $key == 't.rowid' for the columns with the type 'integer'. If you make a call to 'fetchall' with another column being also an integer it goes to the 'else' part of the test and fails

So the point is to know if a call to 'fetchall' using the bom class is officially authorized or not by the authors of the class for any column with the type integer, or if it's limited and documented to be used only with t.rowid

[dpriskorn]

Is this still present in v14?