0019683: Support attaching multiple files with same name - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0019683	mantisbt	attachments	public	2015-05-01 01:36	2015-09-06 17:37

Reporter	vboctor	Assigned To	vboctor
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	closed	Resolution	fixed
Product Version	1.3.0-beta.2
Target Version	1.3.0-beta.3	Fixed in Version	1.3.0-beta.3

Summary	0019683: Support attaching multiple files with same name
Description	At the moment if users attempt to upload a file with the same name, we provide an error message. We should rename the file to make it unique rather than rejecting it. For example: my-patch.diff to my-patch-2.diff, my-patch-3.diff. somefile to somefile-2 and somefile-3. The reasons this feature is useful are: A user is working on a patch, and uploading it to the issue multiple times doesn't need to manually keep track of renaming it. If there is email reporting, then a user may not be looking at the issue and tracking what unique name to use when the email is sent out. For example, user edits a document and re-attaches it. This will make attaching files more user friendly.
Tags	mantishub

vboctor 2015-05-01 01:40 manager ~0050681	Here is the pull request: https://github.com/mantisbt/mantisbt/pull/603

atrol 2015-05-01 08:02 developer ~0050682	Another option could be to ask the user if he wants to replace the existing file or create a new version. You might also think about keeping the file name for the new file, but rename existing files. So the file name in MantisBT keeps aligned with the file name on your local system.

vboctor 2015-05-01 11:36 manager ~0050684	Thanks @atrol for the feedback. I don't like to change older files, since this means that we will have to reflect that in the history somehow and potentially impact notes by even other users that may have referred to the old file. In the case of email integration scenarios, there is no interactive UI to ask the user this question. I prefer the current solution since it is low friction and doesn't change history and hence shouldn't be confusing. The filename modifications also kind of reflects versions of the file.

dregad 2015-05-02 09:19 developer ~0050687	I kind of like the idea of being able to optionally overwrite an existing attachment as a single step (assuming the file bears the same name and user is original uploader or is authorized to delete attachments). With regards to your 1st bullet, it's not so different from a manual deletion, and I don't believe it's a big deal. In terms of history, this could be recorded as 2 distinct events, 1. deleting the old file and 2. uploading new one. That being said, your solution works and the "replace" option is just a nice to have.