Item5384: Allow Delete of Duplicate Attachments

TWiki:Codev.ImproveAttachmentToTrashFlow was written by ArthurClemens who said (before I pointed the content to here)

When an attachment is deleted it is, by default, put into Trash.TrashAttachment. This causes problems if many users delete a file with the same name. It already causes a problem when 2 people have the same attachment, which is not so rare if they attach screenshots made on a Mac that are typically named "Picture 1", "Picture 2", and so on.

Feature Proposal: Improve attachment-to-Trash flow

This topic is currently held up on on impact, below, which essentially asks whether it is okay to change all behaviours where attachments are renamed. (Trash is implemented using the same mechanism as normal renames). Currently renaming an attachment is prevented in the event that an attachment by that name already exists. The proposal would make all such renames succeed, only have later items named from Oneweb.Firstopic.Attachment to AttachmentNN where is progressively higher and as such does not conflict.

-- MartinCleaver

Motivation

What should the user do?

1. After having clicked attachment manage -> delete: leave the page and go to Trash Web
2. Create a new page inside Trash
3. Again go to the delete attachment page (2 steps)
4. Type in the name of the newly created topic and submit

This is a pain.

The situation gets worse in a TWiki app if you simply want to delete an attachment. There is no way to get around above scenario, because:

1. The topic must exist
2. The attachment will not be renamed

Proposal

TWiki stores all deleted attachments on Trash:TrashAttachment (Arthur did mention that duplicate attachments could be stored elsewhere but this is excluded in this revised proposal because it doesn't follow the pattern used for topics). I think we should use the same autorename scheme as used for topics to delete attachments that have already been deleted.

Phasing

1. Provide a system that simply doesn't give an error when a duplicate attachment is filed. Instead have it rename the duplicate to a different name.
   1. To optimise, it could delete an attachment that has both the same name and the same content
   2. It would be acceptable to fail when it tries to automatically restore an attachment back to the same name. (It would likely pick the first or last copy)
2. Handle restores of attachments that had duplicate names
   1. Give a menu to the user which ones to restore
   2. Optionally only allowed to restore those attachments written by the current user.

Implementation Context

Trashing attachments is implemented in Manage.pm as a rename of the attachment from the current location to the topic Trash.TrashAttachment. It is currently considered an error to move an attachment to a page on which an attachment of the same name already exists, so TWiki prevents this happening by raising an exception. http://develop.twiki.org/svn/twiki/trunk/core/lib/TWiki/UI/Manage.pm line 332 (as of Feb 22, 2008)

if( $newWeb && $newTopic ) { TWiki::UI::checkTopicExists( $session, $newWeb, $newTopic, 'rename');

# does new attachment already exist? if( $store->attachmentExists( $newWeb, $newTopic, $attachment )) { throw TWiki::OopsException( 'attention', def => 'move_err', web => $oldWeb, topic => $oldTopic, params => [ $newWeb, $newTopic, $attachment, $session->i18n->maketext( 'Attachment already exists in new topic') ] ); }

Impact

Because this uses the standard rename mechanism, the quickest change (altering this block of code to behave as per Proposal, above) would also alter how normal renames work. This may be unacceptable.

It is not possible to implement this as a plugin because the tests are performed in the user interface, before the plugin hooks are invoked.

If the community deems that changing the standard rename functionality is not acceptable then much of trash attachment must be rewritten. (e.g. This would be the case existing behaviour of attachments moved to another topic where that attachment of that name already exists must fail)

As this behaviour presently exhibits only at the user interface it might be claimed that this will only affect human rather than programmatic access.

Rename Scheme Discussion

This scenario is parallel in many ways to Item23 which had TWiki have issues when the user tried to delete a topic that had already been deleted:

1. More topic actions | Delete topic... if a topic of the same name as the one you're deleting already exists in the Trash web, you get an "Ad­ministration Error"
2. i propose to make topics in the Trash web have a unique name (checked when they're moved to the Trash web) (simplest thing is to generate a new name when displaying the oops "delete topic" page (where it says "If this topic already exists in the Trash web you can specify a different name, e.g. TestTopic41234")
3. Even though topics would then have different names than they originally did, it doesn't matter because of the handy "Put it back" button which will restore the topic to its original web and name
4. SVN 4364. When there's a clash, it first prepends the originating web name, then if that still conflicts a number is added and incremented until a non-conflicting name is found. So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, first "TellMeAGoodStory" is tried, then "TellMeAGoodStory1" then "TellMeAGoodStory2" etc.

By extension, here's a proposal for the same pattern to be used when a duplicate attachment is deleted:

1. Make attachments onto the Trash.TrashAttachment page have a unique name (checked when they're moved to the Trash web) , which adds something to make it unique, either:
   1. A number
   2. The name of the user
   3. The timestamp of the delete operation
2. Even though attachments would then have different names than they originally did, it wouldn't matter if a "Put it back" button could restore the topic to its original web, topic name and attachment name
3. SVN 4364. When there's a clash, it first prepends the originating web name, then if that still conflicts a number is added and incremented until a non-conflicting name is found. So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, first "TellMeAGoodStory" is tried, then "TellMeAGoodStory1" then "TellMeAGoodStory2" etc. - This makes me wonder why trash for all webs ends up into the same Trash web. Would it make more sense to have a Trash web per web, perhaps as a subweb of that web?

Support for Autorename

• Autorenaming would be handy indeed, next to the option to custom rename. -- ArthurClemens - 27 Feb 2007
• This is a usability issue. Yes, auto-rename when needed is a good approach. -- PeterThoeny - 27 Feb 2007
• Agree, this would be very helpful. -- KeithHelfrich - 28 Feb 2007
• I fully support this FeatureRequest. * -- MichaelDaum - 27 Feb 2007

Additional features

When undeleting attachments the auto-rename scheme should be transparent enough to guess which one is the right one based on the timestamp and the user name.	MichaelDaum - 27 Feb 2007

Should be taken to http://twiki.org/cgi-bin/view/Codev/TWikiFeature04x02 per our current process if someone wants to have this decided.

-- TWiki:Main.KennethLavrsen - 23 Feb 2008

I implemented basic support, similar to topics, for renaming attachments. Didn't do the "put it back" options, so leaving this open.

Checked in to trunk, feedback invited.

-- CrawfordCurrie - 30 Apr 2009

Works perfectly.

-- MichaelDaum - 10 Jun 2009

Yes. It is a good simple solution that takes some pain from the enduser. And it does not have to be more overengineered. It is a fine solution that still allows an admin to put it back should a user have deleted an attachment by accident.

-- KennethLavrsen - 16 Jun 2009

The original problem has been addressed partly by allowing a different name for the attachment. It would be better if the system alerts the user an attachment with that name already exists. Follow up in Item9580.

-- ArthurClemens - 28 Aug 2010