Uploaded files deletion identifier

[GoogleCodeExporter]

The new feature we added to the Attachments extension allowing customers to 
delete files they've uploaded before checking out has a flaw.

- Go to 
http://ec2-174-129-95-130.compute-1.amazonaws.com/mageimage/index.php/test/multi
-upload-product.html
- Upload some files in both fields and make sure you have one file uploaded in 
both fields (identical_files.png)
- After they finish uploading, delete the duplicate file from one of the fields 
and place the order.

Go to admin and try to download the same file that was uploaded through the 
other field. You'll get a 404 page.

Original issue reported on code.google.com by agur...@gmail.com on 23 Feb 2011 at 3:21

Attachments:

• identical_files.png

[GoogleCodeExporter]

Original comment by zetapri...@gmail.com on 24 Feb 2011 at 7:00

[GoogleCodeExporter]

I am guessing that this is because magento stores files by making filenames in 
the form of md5 hash after the contents of the file and if file exists file is 
not uploaded again. So uploading the same file more than once will not result 
in many files uploaded but just one, and deleting it will of course affect all 
references to it.

Original comment by jamb...@gmail.com on 24 Feb 2011 at 8:21

[GoogleCodeExporter]

Doesn't sound right.
Kill the reference, not the file.

Original comment by zetapri...@gmail.com on 24 Feb 2011 at 8:25

[GoogleCodeExporter]

Yeah but to know that it has many references I have to do many checks. And if I 
skip the checks and just delete file name from the list then what is the point 
in being able to pretend to delete files there at all.

Original comment by jamb...@gmail.com on 24 Feb 2011 at 8:27

[GoogleCodeExporter]

Will see if I can change the way files are stored.

Original comment by jamb...@gmail.com on 24 Feb 2011 at 8:35

[GoogleCodeExporter]

Hold on.
Why do you need to delete the file at this stage?
Leave it there. 
It will be deleted as an orphaned file some time later.
Don't see a problem with it hanging around for some time.

Original comment by zetapri...@gmail.com on 24 Feb 2011 at 8:41

[GoogleCodeExporter]

Petar, please, post the solution we discussed and 2 test cases (1 order / 2 
orders).

Original comment by zetapri...@gmail.com on 24 Feb 2011 at 9:37

• Added labels: 0.5

[GoogleCodeExporter]

Problem is that magento will not store same file more than once and if file is 
added more than once to an order or to more than one order it still remains 
only one file.
This is good for space but in case that file is deleted all other references 
will point to nothing, and this is probably not wanted behavior.
Proposed solutions:

1. When user attempts to upload same file more than once per order, upload file 
only once and the rest just list. Potential problem is that browsers do not 
know if it is actually the same file - for example C:\images\big\image1.jpg and 
C:\images\thumbnails\image1.jpg are probably different sizes of same picture 
but when uploading them browser only sees image1.jpg and has no way to tell for 
sure if it is the same file.

2. When user clicks on delete file - all you do is delete session reference 
from file table and remove mark that entry as deleted on file list, without 
actually deleting the file.

3. Redefine the way magento actually sets filenames to allow multiple copies of 
same file to be saved. This is useful when uploading same file in more than one 
order and deleting the file for one of the orders will not delete it for the 
rest.

To test 1. you need to upload a file and then check it is listed in backend 
table, then try to upload the file again. The file should appear as if it has 
been uploaded but in backend table no new entries should show.

To test 2. when file is uploaded, click on delete icon, file should be marked 
as deleted but on backend it should be still listed. When order is completed, 
file should not appear as part of order files in frontend and should not have 
associated order id in backend.

To test 3. add same file to more than one order (order should be completed). In 
backend make sure that filename appears next to each order it has been placed 
to. Delete one or more of the same files. Make sure that what is left can be 
downloaded and points to same file.

Original comment by jamb...@gmail.com on 24 Feb 2011 at 10:12

[GoogleCodeExporter]

Solution for the problem applied in version 1.0.4b (not uploaded to magento 
connect yet).
Code revision: r1421
I have also added a list of things to test in a wiki page AttachmentsTesting . 
If you see that I have forgot to add some test cases there, edit the page and 
add them.
With this update, you should be able to download any file from admin table, 
upload same file more than once on same page and even in same widget.
Same files will be listed in all tables and file lists but only one copy of the 
file is actually saved to disk.
Deleting file on frontend will only detach the file from order process. Actual 
file deletion is possible only in admin.
Physical file deletion happens only when there are no more records of the file 
in attachments table.

Original comment by jamb...@gmail.com on 4 Mar 2011 at 4:11

• Changed state: ToTest

[GoogleCodeExporter]

1.0.4b is installed on mageimage, and just uploaded to magentocommerce.com

Original comment by jamb...@gmail.com on 4 Mar 2011 at 4:14

[GoogleCodeExporter]

Tested on /mageimage/
ZetaPrints_Attachments  1.0.4b (beta)
on this product
http://ec2-174-129-95-130.compute-1.amazonaws.com/mageimage/index.php/magentot-0
1/1pg-template.html

Attachment settings page in Magento admin shows 404 Err. The rest is fine.

Original comment by agur...@gmail.com on 4 Mar 2011 at 5:38

• Changed state: MoreWork

[GoogleCodeExporter]

Do you mean this page(attached file)?
It opens for me from menu and from configuration page.

Original comment by jamb...@gmail.com on 6 Mar 2011 at 10:23

Attachments:

• att_settings.PNG

[GoogleCodeExporter]

Hm, I can reach it now no problem. Might have been a glitch, can't replicate it 
now.
Flagging it Test OK, we'll see if it comes up in the future.

Original comment by agur...@gmail.com on 7 Mar 2011 at 10:45

• Changed state: TestOK

[GoogleCodeExporter]

Original comment by zetapri...@gmail.com on 7 Mar 2011 at 9:33

• Changed state: Done
• Added labels: Period-2011-03