create new tag
, view all tags

Feature Proposal: Rename Attachment to Match Latest Upload


I don't think it's intuitive to users that a file is re-named to match the existing attachment name if you upload a new file from manage/update attachment screen.

Description and Documentation

When you update an existing attachment by uploading a new file from the "manage" screen, TWiki makes the new file conform to the existing name. So if your attachment was called Sample.doc, and you upload a new version called Sample2.doc, it changes the latter's name to Sample.doc.

It seems to me that it should work just the opposite. If a user wants to replace one file with another of a different name, why should TWiki assume that the user wants to preserve the old name?

Given that there is currently no way to simply rename attachments, the approach proposed here would give users a relatively easy way to rename an attachment, by simply re-uploading the same file with a different name.



WhatDoesItAffect: Rendering, UI, Usability


-- Contributors: GarySprague - 15 Aug 2008


Agreed, renaming should not be done without the user's permission. In a bug topic we already had a small discussion about this. We need to add a dialog if the user wants to rename the file.

Of course this might get very annoying, a dialog after every file upload. Could we make the dialog so that it appears after the upload, and allows the user to quickly rename the file, as simple as clicking a link?

-- ArthurClemens - 16 Aug 2008

How about a radio button. Use uploaded name, use existing name?

I prefer the current implementation, to use the server's name. It's important because people store locally as XXX.doc, XXX v2.doc, XXX v3.doc yet TWiki does that versioning.

-- MartinCleaver - 16 Aug 2008

We are starting to use TWiki for our requirement document managent. I have not yet convince our people to actually write them on TWiki, so what we are doing is to attach these documents into their corresponding ticket.

Problem is, we do need to put the version number in the name of the file as these documents are sent to our clients for review and approval. This has caused that we're not using TWiki versioning, but each and every revision is being attached independenlty.

I like the radio button idea. I would like it even more if I'm able to specify the default, but I can live without it.

-- RafaelAlvarez - 16 Aug 2008

What about something similar to what happens when you rename a web...It loads the rename page with the current web name already in there, and then you can edit it as you wish before actually hitting Rename.

So I'm imagining on the Update Attachment/Manage screen, just below the file path field, there would be an "Attachment Name" field, and that could auto-fill with the existing name, but allow the user to edit it as desired before hitting "Upload File."

Not sure what the implementation requirements for this approach would be, but I think it would give maximum flexibility without further complicating the update process for the majority of cases where the user is fine with preserving the existing name. It would also allow you to enter a completely different name from the actual file names, which right now is not possible at all.

-- GarySprague - 18 Aug 2008

Good suggestion. We need to add renaming of attachments in any case. Especially when moving attachments to Trash.

-- ArthurClemens - 19 Aug 2008

I had this issue also already. It would be very helpful to preserve the filenames to keep links up-to-date or to change them accordingly. +1 for file-renaming from me.

-- MartinSeibert - 20 Aug 2008

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2008-08-20 - MartinSeibert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.