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 Someweb.Sometopic.AttachmentNN where is progressively higher and as such does not conflict.
--
MartinCleaver
Motivation
What should the user do?
- After having clicked attachment manage -> delete: leave the page and go to Trash Web
- Create a new page inside Trash
- Again go to the delete attachment page (2 steps)
- 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:
- The topic must exist
- 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
- 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.
- To optimise, it could delete an attachment that has both the same name and the same content
- 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)
- Handle restores of attachments that had duplicate names
- Give a menu to the user which ones to restore
- 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:
- 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 "Administration Error"
- 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")
- 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
- 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:
- 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:
- A number
- The name of the user
- The timestamp of the delete operation
- 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
- 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
This bug is also reported at
Item4514.
--
TWiki:Main.PeterThoeny
- 09 Apr 2009
I think the webname prefix is a bit overkill. The "put it back" offers an easy way to undelete. Perhaps change the spec to:
So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, try "AGoodStory1" then "AGoodStory2" etc.
--
TWiki:Main.PeterThoeny
- 27 Oct 2009
Above spec is way too complicated. I suggest a simple spec:
Proposed spec: When deleting an attachment and if attachment already exists in Trash.TrashAttachment, do a sequential numbering on file name, such as
example.pdf
,
example2.pdf
,
example3.pdf
, etc.
--
TWiki:Main.PeterThoeny
- 2011-01-31