Questo bug resiste da alcune versioni. Vediamo come risolverlo.
La risoluzione del bug prevede l’applicazione di modifiche NON upgrade-safe. Questo significa che in caso di aggiornamenti del CRM, le modifiche potrebbero andare perse.
Il file da modificare è:
Api/V8/JsonApi/Repository/Filter.php
All’interno della funzione “parseWhere” , trovere il ciclo foreach mostrato sotto (il numero di riga può essere diverso in base alla versione)
1 2 3 4 5 6 7 8 9 10 11 12 |
foreach ($expr as $op => $value) { $this->checkOperator($op); $where[] = sprintf( '%s.%s %s %s', $bean->getTableName(), $field, constant(sprintf('%s::OP_%s', self::class, strtoupper($op))), $this->db->quoted($value) ); } |
Nota Tecnica: Come si può vedere la costruzione della query all’interno del ciclo considera solo la tabella originale e non quella “_cstm” che è la tabella del DB dove vengono salvati i campi custom aggiunti dallo studio. Quello che faremo è di intercettare i campi cutom e smistare le richieste sulle tabelle corrette.
Di seguito la patch da sostituire al ciclo mostrato in precedenza
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
foreach ($expr as $op => $value) { $this->checkOperator($op); //BUG FILTRO CAMPI CUSTOM if ( substr($field, -2) === "_c" ){ $where[] = sprintf( '%s.%s %s %s', $bean->getTableName().'_cstm', $field, constant(sprintf('%s::OP_%s', self::class, strtoupper($op))), $this->db->quoted($value) ); }else{ $where[] = sprintf( '%s.%s %s %s', $bean->getTableName(), $field, constant(sprintf('%s::OP_%s', self::class, strtoupper($op))), $this->db->quoted($value) ); } } |