--- Attachments / File Uploads ---

I was not able to reproduce your problem with a fresh install of 1.3.0-rc.1, attachments can be added without errors. I tested on Linux, PHP 5.5 and MySQL 5.5, but I don't think that should make any difference.

I suspect you're not running standard MantisBT code, because the SQL statement you reported does not match what is executed by the file API [1] (your query does not include the 'content' column).

[1] https://github.com/mantisbt/mantisbt/blob/release-1.3.0-rc.1/core/file_api.php#L1054

I'm using standard MantisBT code without any changes. Did yo test it with an existing database from an older version?

but I don't think that should make any difference.
Me too, but

PHP 5.6.0
This is certainly not a good one, the latest one at the moment for 5.6 is 5.6.17 [1]
I remember users having problems using early 5.6 versions.

@dregad, 1.3.0-rc.2 will come with an updated adodb version.
Maybe there are changes in it that affect this issue.

[1] http://php.net/ChangeLog-5.php#5.6.17

@dregad, 1.3.0-rc.2 will come with an updated adodb version.
Maybe there are changes in it that affect this issue.

No. I tested both with 1.3.0-rc.1 and master, and was not able to reproduce on either versions. Including with a DB installed under 1.2.19 and upgraded afterwards.

@DLeon, sorry but I maintain that the query

INSERT INTO mantis_bug_file_table ( bug_id, title, description, diskfile, filename, folder,

filesize, file_type, date_added, user_id )

VALUES

( ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )

does not exist anywhere in 1.3.x code. The code reference I provided in 0020547:0052417 is the only occurence of an insert statement on mantis_bug_file_table.

Maybe you can provide the output of the error page, with $g_detailed_errors = ON; this may help understanding what the problem is.

Thank you all for your answers. I know that the query in the error message is different from the Insert query in file_api.php. It seems that Content may be NULL. I switched g_detailed_errors to ON and got the following error message:

INSERT INTO mantis_bug_file_table ( bug_id, title, description, diskfile, filename, folder,
filesize, file_type, date_added, user_id )
VALUES
( 1270, '', '', 'ad56347a65d9b42f9270a141942a05ed', 'pic.jpg', '', 748577, 'image/jpeg', 1454003023, 2 ).

My logfile Shows the same query:
28-01-2016 18:43 CET DB array (
0 => 'INSERT INTO mantis_bug_file_table ( bug_id, title, description, diskfile, filename, folder,
filesize, file_type, date_added, user_id )
VALUES
( 1270, \'\', \'\', \'ad56347a65d9b42f9270a141942a05ed\', \'pic.jpg\', \'\', 748577, \'image/jpeg\', 1454003023, 2 )',
1 => '0.0000',
)

And here the query of my file_api.php
$t_query = 'INSERT INTO {bug_file} (
bug_id, title, description, diskfile, filename, folder,
filesize, file_type, date_added, user_id, content
)
VALUES ( '
. db_param() . ', ' . db_param() . ', ' . db_param() . ', '
. db_param() . ', ' . db_param() . ', ' . db_param() . ', '
. db_param() . ', ' . db_param() . ', ' . db_param() . ', '
. db_param() . ', ' . db_param() .
')';
db_query( $t_query, array(
$p_dest_bug_id, $t_bug_file['title'], $t_bug_file['description'],
$t_new_diskfile_name, $t_new_file_name, $t_file_path,
$t_bug_file['filesize'], $t_bug_file['file_type'], $t_bug_file['date_added'],
$t_bug_file['user_id'], $t_bug_file['content']
) );

Really strange! Content is missing.

The query is here:
https://github.com/mantisbt/mantisbt/blob/release-1.3.0-rc.1/core/file_api.php#L725

@DLeon
your mysql version seems a bit old (5.1)
This can be related: http://bugs.mysql.com/bug.php?id=25520

Don't know if its a inherent problem on mysql core, or its solved by newer versions

Again thanks for your support.

@cproensa
You're right, the query is in line 725 not in 1054.

And this query changed from version 1.2.19. So maybe other people will have the same problem.

@cproensa
The link is helpful. Text and blob are not allowed to have set default values. This ist not a bug but a rule also for new versions of the mysql server. With sql mode 'STRICT_TRANS_TABLES' is becomes an error, without this mode it is only a warning and uploading files is possible.

So the solution for me is now to globally disable the STRICT_TRANS_TABLES mode.

@DLeon:
I tried with 1.3.master branch, setting manually STRICT_TRANS_TABLES on and off, and always could report a bug with attachment
My system is linux, so i cannot test on windows based mysql.

@cproensa
Did you change the setting globally or per session?

@cproensa

I used the following way:

set GLOBAL sql_mode='';
SELECT @@GLOBAL.sql_mode;

good pint, i probably changed only for current session

i will try again

/me needs glasses. And maybe a 'good pint' too ;-)

Apologies for my earlier comment, I failed to see that query. Thanks cproensa for pointing it out.

So, the issue has most likely been introduced by MantisBT master 12a7f834 - instead of doing a single insert, the code performs the update in 2 steps, insert basic data then update the blob.

I still find it strange to have this error since

1. we do NOT specify a default value on this column
2. MySQL automatically sets the default to NULL when none is specified

Anyway, I will now try to replicate the problem using SET sql_mode = 'STRICT_ALL_TABLES'.

@dregad
in my db that field was defined as NOT NULL. Does it sound suspicious?

Still not able to reproduce - inserting attachment is successful even when sql_mode is STRICT_ALL_TABLES (the 1st 2 log entries in the extract below are the result of debugging statements I added).

2016-01-29 17:10 UTC DB file_api.php:726 file_add() array (

0 => 'SELECT @@sql_mode',

1 => '0.0003',

)

2016-01-29 17:10 UTC DB file_api.php:727 array (

'@@sql_mode' => 'STRICT_ALL_TABLES',

)

2016-01-29 17:10 UTC DB file_api.php:734 file_add() array (

0 => 'INSERT INTO mantis_bug_file_table ( bug_id, title, description, diskfile, filename, folder,

filesize, file_type, date_added, user_id )

VALUES

( 2, \'\', \'\', \'95de937370a6d220630483d48f4c95c3\', \'1.patch\', \'\', 1117, \'application/octet-stream\', 1454087408, 1 )',

1 => '0.0006',

)

Can you share the structure of your table's content column (i.e. desc mantis_bug_file_table content) ? For the record, mine's like this, both in a fresh 1.3.0-rc.1 install, and from the one I upgraded from 1.2.19.

mysql> desc mantis_bug_file_table content;

+---------+----------+------+-----+---------+-------+

| Field   | Type     | Null | Key | Default | Extra |

+---------+----------+------+-----+---------+-------+

| content | longblob | YES  |     | NULL    |       |

+---------+----------+------+-----+---------+-------+

1 row in set (0.00 sec)

I think this is ADOdb related

My DB for 1.3-master was migrated from 1.2.3, and i have:

mysql> desc mantis_bug_file_table content;

+---------+----------+------+-----+---------+-------+

| Field   | Type     | Null | Key | Default | Extra |

+---------+----------+------+-----+---------+-------+

| content | longblob | NO   |     | NULL    |       |

+---------+----------+------+-----+---------+-------+

Other DBs, created by 1.3-beta3 and 1.2.19, both show:

+---------+----------+------+-----+---------+-------+

| Field   | Type     | Null | Key | Default | Extra |

+---------+----------+------+-----+---------+-------+

| content | longblob | YES  |     | NULL    |       |

+---------+----------+------+-----+---------+-------+

So i tried, with 1.3 master:

$schema[] = array( 'CreateTableSQL', array( 'blob_test2', "

content B NOTNULL ",

$t_table_options

) );

mysql> desc blob_test2 content;

+---------+----------+------+-----+---------+-------+

| Field   | Type     | Null | Key | Default | Extra |

+---------+----------+------+-----+---------+-------+

| content | longblob | YES  |     | NULL    |       |

+---------+----------+------+-----+---------+-------+

So i am saying NOT NULL, but the field is created as NULL. Maybe its a conversion made by ADOdb by itself.

Once reproduced in my affected DB,
I got to fix the problem adding an explicit "content" field in the insert statement, and using 'empty_blob()' as value (string).
ATM I don't know if it may cause any regression, but if this works, may be less hassle that modify schema

@DLeon:
Did you migrate you current DB from previos versions <1.2.19?
If so, this may be the explanation.

I think this is ADOdb related

You're right, but not upstream adodb - rather a consequence of our specific patches in 1.2.

Using the following test code

<?php

include('library/adodb/adodb.inc.php');

$db = ADONewConnection('mysqli');

$db->connect('localhost',$u,$p,'test');

$dd = NewDataDictionary($db);

$dd->CreateTableSQL('a', 'b B notnull');

print($dd->CreateTableSQL('a', 'b B notnull')[0]);

The following SQL is generated (extra whitespace removed):

1.2: CREATE TABLE a ( b LONGBLOB NOT NULL )
1.3: CREATE TABLE a ( b LONGBLOB )

I also checked with upstream ADOdb 5.10 (which is the version we use in 1.2), and the datadict generates the same SQL as 1.3. Ergo, this does comes from a MantisBT-specific change to the library, traced to MantisBT master 19dbfb0e.

I think the right approach to address this issue is to fix the insert statement to populate the content column.

To reproduce the problem, execute the following SQL commands:

set global sql_mode = 'STRICT_ALL_TABLES';
alter table mantis_bug_file_table modify content longblob not null;

Adding an attachment in Mantis then triggers application error 401 (file_api.php, line 731)

Database query failed. Error received from database was #1364: Field 'content' doesn't have a default value for the query: INSERT INTO mantis_bug_file_table ( bug_id, title, description, diskfile, filename, folder,
filesize, file_type, date_added, user_id )
VALUES
( ?, ?, ?, ?, ?, ?, ?, ?, ?, ? ).

Please see proposed fix in PR https://github.com/mantisbt/mantisbt/pull/715

Seems not to be just a MySQL issue with sql_mode = 'STRICT_ALL_TABLES' but also a SQL-Server issue:
https://www.mantisbt.org/forums/viewtopic.php?f=2&t=23590