Feature Proposal: Improve attachment-to-Trash flow

When a attachment is deleted is is put by default 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.

This is being described and tracked at TWikibug:Item5384

-- ArthurClemens

Waiting for decision on impact

This topic is currently held up on on impact, as described on TWikibug:Item5384, 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

Discussion

I fully support this FeatureRequest.

-- MichaelDaum - 27 Feb 2007

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

There is also a security loophole. The Trash web is typically open and allows anyone to see deleted attchments from secure webs.

-- PankajPant - 22 Feb 2008

We could also change the implementation completely, for instance, deleting topic Web/Topic would:

• Create an auto-numbered topic in Trash, like Trash/Topic63562 (variant: date+serial number, like Trash/Topic20080305x12 )
• The topic and its RCS history would become attachments of this new topic, with standard names (_topic.txt ?), or keeping the same name, or a name found in a form field in the topic to solve automatically name conflicts with existing attachments.
• the topic attachments would become attachments of the new topic (variant: all attachments + RCS files would be zipped and attached as one single file)
• the new topic body will hold metadata (a form? key/values in body?) holding info on the topic: name, attachements, list of editors, summary of history...
• the current access control status (resulting from web + topic protections) would be synthetized into explicit ALLOWTOPICVIEW/CHANGE in the body of the new topic

The benefits:

• no naming conflicts
• no more security loophole
• easily automated for auto-destruction of deleted topics + attachments after some time
• comments can be put in the new topic body (reason for deletion, ...)
• no more user-hostile "non-wikiword" failure when trying to delete wikiword topics in sub-webs (due to TWiki adding underscores to the topic name)

The drawback:

• the manpower to implement it (although it does not seem too hard)

-- ColasNahaboo - 06 Mar 2008

Could this work for deleting just one attachment?

-- ArthurClemens - 06 Mar 2008

I guess, yes, by creating a Trash/Topic87683 with only the attachment attached, but not the topic text

-- ColasNahaboo - 06 Mar 2008

How would one go about retrieving deleted topics or attachments, when it's needed?

-- KwangErnLiew - 06 Mar 2008

• by hand: copy/paste
• we could make the delete script add in the body of the new topic in trash buttons calling a restore script, for everything, or for each part (body + attachment)

-- ColasNahaboo - 07 Mar 2008

The option to rename an attachment when trashing it has been implemented in trunk. In the case it is moved to Trash.TrashAttachment, it would be useful if the rename field offered a safe name that does not clash with existing files.

-- ArthurClemens - 22 Dec 2009