No subject

Wed Nov 27 07:05:18 CET 2013

Especially for the DocModule file upload.
Assumption: Content-hashes are only checked within storage
The cases for uploading a file again are:
1.) same name, same content, override -> mask as successful
Don't think this should be changed. So just override the current file

MK: Ok,=20
2.) same name, same content, no override -> error, tell the user the =
file exists
IMO this one should "mask as successful".

Use-case: Editor uploads some files directly in the content element. =
This way he doesn't have to open the element browser to upload/select =
files to use.
Now he uploads a file he already uploaded some time ago.=20
When we break the upload process with a "File already exists message" =
the editor still has to open the element browser to search and select =
the existing file.

If we "mask as successful" the editor is happy and nobody gets hurt :)
3.) same name, other content, override -> replace the file content and =
keep references=20
4.) same name, other content, no override -> rename the uploaded file
Think this should be the default behaviour again like in the 4.* =
branches. Not the cancel upload as it now is.
5.) other name, same content, override  -> rename the existing file and =
keep references
I'm not sure about this. Are we talking only about files in the same =
Do not think this is wanted behaviour.
6.) other name, same content, no override  -> error, tell user file does =
already exist
If you search for files with the same content it could be thats there is =
a file with the same content but on a location that the editor isn't =
allowed to access.

Furthermore we lack a 'replace' function, to replace an existing file =
with a completely different (other name, other content) file, but =
keeping the references.
This is a MUST HAVE IMHO.=20

What's your opinion about this?

There are currently 3 conflict modes
1. replace
2. cancel
3. changeName

Currently 1 & 2 are in use by the fileupload in BE. But think this =
should be 1 & 3.=20
gr. Frans=20

More information about the TYPO3-team-core mailing list