For what it's worth guys, I saw this this morning:
http://the-stickman.com/web-development/javascript/upload-multiple-files-with-a-single-file-element/

For the interface side of things, I thought it was perfect for the job at hand. I will try and integrate it and see where I end up with it...

Did anyone resolve this in the end?

Would it be possible to just let the browse dialog that comes up be multiple select capable, and then either just put all the files that are needed to be uploaded in the textbox seperated by a semi-colon (which can then be used as a delimiter to loop around) or to dynamically create as many text boxes that are needed? We would also find this feature very useful.

This would be a useful feature indeed.

I've attached multiple_files.zip.
It contains multifile.js and patch.txt (for CVS MAIN BRANCH).

I tried the multiple_files.zip above, but with no success. It still does not allow multiple files. I'm going back through to make sure that all the changes were made properly. No crashes upon implementing, just not additional functionality.

OK, finally came back to this one and reran through all the code entries by hand. Appears to work properly in FF, but in IE6 it does not activate the new functionality. No breakage, just doesn't run.

Page comes up with the following errors in IE6:

Error: 'MultiSelector' is undefined

Clarification to the above: Tested it at home, and it does not work in IE7 either. Same error comes up ("Page loads but with errors").

Hi phoenixcreation.
I found minor mistake in multifile.js.
Replace multifile.js with attached one.

Hi seji,

I've applied your patches to the latest MANTIS release 1.1.0rc3 and it works fine.

One minor flaw I see: Two "upload file" buttons that have the same functionality. Was this done deliberately?
Screenshot attached (german version: "upload file" = "Datei übertragen").

regards,
Stefan

Hi seji,

me again.
The problem with the duplicate button was my bad implementing the patches.
So all your patches work fine with MANTIS 1.1.0rc3.

Thanks for distributing them,
Stefan

Confirmed. Works on IE6 here at work and on IE7 at home. Very nice. :)

Appreciate the work!

Will this patch find it way in on of the next releases?

Applied this patch manually to 1.1.4 and double checked my work. DOES NOT WORK.. When click browse to select, no list comes up.. Then when hit upload, you get

APPLICATION ERROR #1100
Ticket 0 not found.

What am I doing wrong?

Works fine here with all Mantis releases since early 1.1.0 RCs.
For every file to be uploaded you have to hit "browse" and select the file. It will be added to a list that can be transferred all in one go with hitting "Upload files".

Dear All,

I tried to implement this Feature, in my application. I am able to add multiple files, but while im trying to click 'Upload File' button, it is throwing an error as
'File cannot be uploaded, Mantis cannot see the file. Please check the project settings."

Please share your thoughts;

Regards,
Prabhu.

FYI: Im using mantis 1.2.0a3

Regards,
Prabhu

@stefand

As this functionality works fine for you, please let me know what would be wrong in myself. I have added all the changes that have been mentioned in patch.txt; however when im using browse button files get add to the list and while i am trying to hit 'Upload File' button i am facing this issue.

Please share your thoughts in this.

REgards,
Prabhu.

@ Prabhu

So far I've only implemented this in the Mantis 1.1.x branches which works fine, I don't have any clue about this in Mantis 1.2.x. I'm sorry.

Cheers,
Stefan

Hi Stefan,

Thanks for your early reply;

However, any guess on this error message, why this happens.
ERROR:
"File upload failed. File is not readable by Mantis. Please check the project settings."

Is there any format for the files to be uploaded, do we have to perform any settings in our manage projects, to upload files.

Please i don't thing this may be version compatible, as it works fine in 1.1, it should any way work in 1.2;

Or can you please post me your 'Patch.txt' file which you have used.

Regards,
Prabhu

The error is thrown in the file_api.php script when the file is not readable (!is_readable).
Can you upload/save files in the release version of the files, i.e. before you implemented the patch? Where do you save the files, in the db or on the disk?

Yes i could upload files before applying the patch. I would save in DATABASE.

Also i could see the attached file in my mantis_bug_file_table.

Why it could not read this file after applying the patch. But the same file i could upload before applying the patch.

I also save my attachements in the database, so this could not be the problem then.

Have you implemented the patch manually, i.e. migrate the patches which were written for an old Mantis 1.1.x release into new sources of mantis 1.2.x, or did you use a tool that automatically merged the patch into the sources?
If you use a tool, then this definitely would go wrong, as the original sources differ.

But this is all just guessing now...

No stefand; I manually applied the changes to 1.2 release.

In this patch, they have added some lines 'error_parameters($p_filename)' in file_api.php, what this means?

To hunt the issue down:

When does this error happen?
1) Create a new bug and immediately attach files
2) Attach files to an existing bug

This is handled in two different files:
1) bug_report.php
2) bug_file_add.php

Could you pls try both methods and let us know what happens.

I tried to create a new bug and uploaded a file to the bug and clicked 'Submit' in Report issue page, but the file is not uploaded.

Also later once the bug is created, i tried to upload the same file, but it is throwing the error message.

Also i tried to upload a file to already existing file, it throws the same error.

I have an clarification, in the above patch.txt file, some changes are asked to do in core/html_api.php file; Where to add those script, 'function html_multiupload_script()'.

I think i am doing something wrong in this changes.

@stefang

Can you please attach your core/html_api.php file, for reference

I could not even create a new bug from report issue page, if i upload any file. It is throwing the same error message.

Attached is an archive including all changed files against Mantis release 1.1.6.
Did you use the updated multifile.js given above?

Yes. I used the updated multifile.js. Ok let me check with your files and let you know the status. Thanks a lot Stefang.

Or simply use:
http://www.mantisbt.org/bugs/view.php?id=10223

@stefang

Please go through the line mentioned in bug_file_upload_inc.php

'<input id="file" name="file[]" type="file" size="40" />' in this the 'id' and 'name' attribute should be same.

@prabhu

What do you mean by "should be the same"? Is my implementation wrong or what? At least it is exactly what the patch.txt has and for ME it is working and for you not...

Did you succeed with your implementation of my changes?

@stefang

I am still facing the same issue.

However, the HTML standard is 'id' and 'name' attribute value should be same, as Firefox will access by 'id' and Internet Explorer will access by 'name' attribute.
This is an information i need to pass you.

But i am not saying because of this it is not working for me, But i do not know the exact reason.

Can you get me.

Please be patient, if i am wrong in any means.

@stefang

However I need your help in this.

I am having the same issue of having the work against my new 1.2.1 deployment. The JS works (able to "attach" on the screen, but when we go to submit a new issue, or update an existing one, it is unable to find the files for upload.

We are using the alternative version provided above that lists one browse line per file allowed, but that is a little kludgy (no offense) compared to JS version. We had to decrease our max files from 10 to 5 because it added too much to the screen.

Any ideas on how to get this working against a 1.2.1 implementation? Thanks!

I have uploaded the MANTIS1.2.3_UPLOAD_MULTIPLE ZIP file which has 4 PHP files. Unzip them and copy all the 4 to your main Mantis folder (so next to your config_inc.php). 3 files (out of the 4) in the ZIP will overwrite files on your server so however the solution is tested I recommend to create a backup of those files.

Then go to your config_inc.php and add the following variable:

$g_max_file_num = 2;

where the number equals the maximum number of files you want to upload at the same time. (2-3 is recommended)

This ends up in a change in the issue reporting and the issue viewing page where now you are able to add more files at the same time.

The solution is tested under Mantis 1.2.3 and it affects only 3 + 1 files so it is a pretty straightforward operation.

The "View issue" page mod comes from Cas (see issue the related issue 0010223), the "Report issue" page mod comes from me (see related issue 0012526)

@rombert - I had started messing around with this towards end of 2011, but never had the time to finish things... You may want to have a look at the work-in-progress (see the upload-* branches on my github fork), maybe there's something you can reuse.

(In reply to comment 0005228:0031498)

@rombert - I had started messing around with this towards end of 2011, but never
had the time to finish things... You may want to have a look at the
work-in-progress (see the upload-* branches on my github fork), maybe there's
something you can reuse.

I'll do that, thanks!

(In reply to comment 0005228:0031498)

@rombert - I had started messing around with this towards end of 2011, but never
had the time to finish things... You may want to have a look at the
work-in-progress (see the upload-* branches on my github fork), maybe there's
something you can reuse.

Damien, I've taken a look at your upload-multi branch and as far as I can tell this is feature complete. I've added to the docbook documentation but that's about it.

Did you plan on doing anything else?

To be honest that's a long time ago so you're asking much from my poor Swiss-cheese brain ;-)

As far as I can remember, I had most of the code down, and had started on testing but never finished. I vaguely recall facing issues with error handling, hence the 2 experimental sub-branches, but that might also have been an attempt at fixing the duplicate bug creation issue 0003759.

Note also the missing bug ID in comment for commit 492df564 - I guess I meant to open a new issue for that on the tracker and then forgot to do it. I think the comment should be amended.

I was also thinking about improving the interface using jQuery to dynamically display additional download fields only when they are needed instead of needlessly cluttering the UI with unnecessary fields and buttons.

0005228:0031506

I was also thinking about improving the interface using jQuery ...

Keep in mind that
a) MantisBT should also run with JavaScript disabled in Browser or configuration use_javascript = OFF.
b) jQuery is bundled in master but not master-1.2.x (but available as plugin)

ATM phpBB tries to get similar things done in "Google Summer of Code" [1]
They mentioned integration of Plupload [2]

[1] http://wiki.phpbb.com/GSoC/2012/Ideas#Attachment_Improvements
[2] http://www.plupload.com

@atrol
jQuery was just an idea that I had, indeed targeted at 1.3.x.

I did have a look at a couple of implementations for multi-upload using either js or jQuery, but never went further than that.

Thanks for the references anyway. Might be useful in avoiding reinventing the wheel.

This is now fixed in both master and master-1.2.x. Damien, thanks for your work, I merely documented and pushed the changes.

the HTML5 multi-upload for sf.net is an open source project and it seems to work fairly well and handles fairly large files. it's slick.
I could find out what project it is.

the html5 upload I saw automatically added file browse buttons as needed, you could select multiple files in your upload for one browse button. so essentially, you can go wild with it. it even I think gives a progress bar while you upload.

(In reply to comment 0005228:0031526)

the HTML5 multi-upload for sf.net is an open source project and it seems to work
fairly well and handles fairly large files. it's slick.
I could find out what project it is.

That would be of interest to me. The only note is that, as atrol has noted, we need to work without javascript and we can't rely on jQuery in the 1.2 branch. We can implement it in the 1.3 branch however.

http://pypi.python.org/pypi/gp.fileupload/1.1
it is python WSGI package.
to get the fancy multi-file-browse uploads, apparently you have to use jquery. there may be workarounds(?).
the linux disros I know of all come with firefox, and JS enabled.

@rombert

I just re-checked, and indeed as I mentioned in 0005228:0031506, the error handling for simultaneous upload of several files is not satisfactory in my opinion. That is why I did not commit my code back then and started experimenting with alternate error handling solutions (branches upload-err-hndl and upload-err-conv.

Test case:

config_inc.php

$g_file_upload_max_num = 3;
$g_max_file_size = 1000;

a. attach several documents: file1, size < 1000; file2, size > 1000; file3, size < 1000
b. click upload - you get Error 500 (File upload failed) as expected
c. click back button
d. refresh page
e. file1 was uploaded successfully, file2 and file3 were not

This is is confusing to users, and furthermore if you do the same when reporting a new issue and then resubmit, you get duplicate issues (see 0003759)

@dregad : how would you see this work? Skipping the failed upload and continuing? Reverting all uploaded files?

I think a failed upload should trigger a warning and let the operation continue. Ideally the confirmation page should display the status of overall operation, listing any file upload failures. I believe such a solution would also resolve 0003759.

is error 500 caused by file permissions?

Marking as resolved in preparation for 1.2.10 release, as discussed with vboctor on the mailing list today. I'll open a separate issue to track the problem with error handling on failed uploads.

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch