Defect #4618

Adding an Attachment to an Issue of the Same Name as Another Attachment Overwrites

Added by Chris Haverman over 3 years ago. Updated 4 months ago.

Status:ClosedStart date:2010-01-20
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Attachments
Target version:-
Affected version:0.8.5 Resolution:Fixed

Description

Steps taken that produce this behavior,

  1. An issue has an attachment made to it (usually in my case, a screenshot)
  2. Another attachment is made, with the same filename as the one from above.

At this point, the new image replaces the other one, and references to it now point to the new one. What I'd want to see is that the new attachment gets renamed so that it doesn't displace the old one.

Extra information:

database: MySQL 5.0.75
ruby: 1.8.7
rails: 2.3.4
redmine: 0.8.5 (I know I upgraded to .5 but all the infos read .4)

History

#1 Updated by Felix Schäfer over 3 years ago

  • Category set to Attachments

Mmh, I was under the impression this was intentional, but I can't find a reference to some statement on that, so I'll let Eric or Jean-Philippe chime in on that one.

#2 Updated by Jean-Philippe Lang over 3 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

Indeed, this behaviour was introduced in r1939.
This is especially usefull in wiki pages when you want to update a screenshoot without having to edit the page.

#3 Updated by Markus Valle-Klann over 2 years ago

  • Status changed from Closed to Reopened

Hi, I just ran into the same issue with attachments having the same file name.

It seems btw that the thumbs plugin is displaying the older (original) attachments so updating wouldn't even work.

I understand the benefit of being able to update screenshots without having to update the page. But I think the disadvantage of not being able to simply attach a file to an update and reference it without having to worry about unique file names weighs more heavily. Especially considering the difficulties novice users are typically having.

In any case, wouldn't it be possible to resolve this in case of a file name collision by giving the user the option to 1) either really replace an existing attachment with the same name (if that's what is intended) or 2) to make it unique and automagically update any references to this atttachment in the update.

I took the liberty of reopening this issue in the hope the update doesn't get lost... If that was against protocol, my apologies and please revert.

#4 Updated by Daniel Felix 4 months ago

  • Status changed from Reopened to Closed
  • Resolution changed from Wont fix to Fixed

I just checked this issue with Redmine 2.2.1.

I'm not able to reproduce this. This issue is fixed. I tested the issue modul, as described in the issue description.

Also available in: Atom PDF