Glpi: 9.1.1: Can't add delivery date to Monitors via massive action

[pVesian]

Hi,

On the Monitors list (/front/monitor.php), I can't add/change a delivery date via massive action.
I've tested with today, past and future dates. I've also tested most of other fields, they all work.

From a code perspective, in massiveaction.class.php I enter } else { /// Not infocoms, which shouldn't happen, since it's infocom.
var_dump('isInfocomOption', $item->getType(), $index, Search::isInfocomOption($item->getType(), $index)); outputs string(15) "isInfocomOption" string(7) "Monitor" string(3) "142" bool(false), so I guess it should be added to the list?

To reproduce: have a list of monitors, select a few, or even 1, and use the massive actions to change the delivery date. Feedback will say the change was done. Go to one of the monitors and look, the change wasn't done.

System:

[code]

GLPI 9.1.1 (/glpi => /var/www/html/glpi)

Server


Operating system: Linux model-ubuntu 3.13.0-30-generic #54-Ubuntu SMP Mon Jun 9 22:47:59 UTC 2014 i686
PHP 7.0.14-1~dotdeb+8.1 apache2handler (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, calendar,
    ctype, curl, date, dom, exif, fileinfo, filter, ftp, geoip, gettext, gmp, hash, iconv, imap, intl, json, ldap, libxml, mbstring,
    mcrypt, msgpack, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, posix, readline, session, shmop, soap, sockets, sqlite3,
    standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files"
    upload_max_filesize="2M" 
Software: Apache/2.4.7 (Ubuntu) (Apache/2.4.7 (Ubuntu) Server at localhost Port 80)
    Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0
Server Software: (Ubuntu)
    Server Version: 5.5.35-1ubuntu1
    Server SQL Mode: 
    Parameters: root@localhost/glpi
    Host info: Localhost via UNIX socket

OK/var/www/html/glpi/config : OK
OK/var/www/html/glpi/files : OK
OK/var/www/html/glpi/files/_dumps : OK
OK/var/www/html/glpi/files/_sessions : OK
OK/var/www/html/glpi/files/_cron : OK
OK/var/www/html/glpi/files/_graphs : OK
OK/var/www/html/glpi/files/_lock : OK
OK/var/www/html/glpi/files/_plugins : OK
OK/var/www/html/glpi/files/_tmp : OK
OK/var/www/html/glpi/files/_rss : OK
OK/var/www/html/glpi/files/_uploads : OK
OK/var/www/html/glpi/files/_pictures : OK
OK/var/www/html/glpi/files/_log : OK
Web access to the files directory, should not be allowed
Check the .htaccess file and the web server configuration.

[btry]

Hi

Do php-errors.log or sql-errors.log contains errors ?

[pVesian]

No, no errors

[btry]

I think the patch I just submitted should solve your issue. Can you validate it too ?

[pVesian]

Indeed, it fixes the issue.

For an improvement, do you think Search::isInfocomOption() could use some rewriting with constants instead of hardcoded ids? Given the small ranges (25-28, 37-38, etc), it could also benefit from an in_array() instead of comparisons.

[troloff]

I have the same issue with decommision_date, so I guess 159 should be added to the check above, too.

from infocom.class.php
$tab[159]['table'] = 'glpi_infocoms'; $tab[159]['field'] = 'decommission_date'; $tab[159]['name'] = __('Decommission date'); $tab[159]['datatype'] = 'date'; $tab[159]['forcegroupby'] = true; $tab[159]['joinparams'] = $joinparams;

[btry]

Hi @troloff

Please open a new issue, and if you think it is related to this one, mention it (using #number) in your description.