Bug 82856 - Moving a message will put a copy of the message in the trash
Moving a message will put a copy of the message in the trash
Status: CLOSED WONTFIX
Product: Red Hat Public Beta
Classification: Retired
Component: evolution (Show other bugs)
phoebe
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-27 14:30 EST by Thomas M Steenholdt
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-02 00:55:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas M Steenholdt 2003-01-27 14:30:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030115

Description of problem:
When moving a message within evolution, for example from the Inbox to a
subfolder called test... The message is moved as expected, but a copy of the
message appears in the Trash for total confusion.

I was poking around in my mailbox the other day, when a notice a whole bunch of
my Red Hat bugzilla mails had accidentially been deleted, so I undeleetd the all
ofcourse... and moved them to my bugzilla folder... Strangely there were many
more of the report messages in my trash so i undele.... I did this 3 times(the
the fault of the bug, but myself - I know) before susepcting that something
fishing was going on. And so I had to clean uop among the many duplicates.
Pretty annoying.

I suspect (without even taking a look at the code) that moving a message in
evolution is not really a move as much as it is a copy and delete process.
Unfortunately, when the process should appear as a move, stuff should not be
left in the trash afterwards!

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a subfolder to Inbox, called test_tempo(?)
2. Make sure your trash is empty(or that you know what's in it)
3. Move a message from the inbox to test_tempo
4. Take a look in the Trash folder
    

Actual Results:  A copy of the just moved message is in the Trash

Expected Results:  There should be no changes to the contents of the trash
folder after a move operation.

Additional info:
Comment 1 Thomas M Steenholdt 2003-01-27 14:31:20 EST
moving to Phoebe - This was not intended as a Roswell incident(!!) - I just
missed Phoebe on the list - sorry for the inconvenience
Comment 2 Jeremy Katz 2003-01-27 17:10:38 EST
This is because the message is copied and then deleted from its original folder.
 The Trash folder is really just a vfolder which shows all deleted messages from
any folders, which this would qualify as.
Comment 3 Thomas M Steenholdt 2003-01-28 02:50:54 EST
I get it! But this still seems very much inconvenient as it easily leads to
confusion, so shouldn't there be some sort of "bypass_trash" option for the
delete function, that should be used when moving mails!

I really fell that this should be fixed. in one way or the other... Moved
messages should not be in the trash as they have not been thrown away!

I just don't know where it is supposed to be fixed; in the move function/delete
function or perhaps in the Trash view? i'd go with the functions as it seems
more correct!

If you still think this is not worth fixing, close the bug again - I did not
re-open the bug to annoy you but i really think you should give it a second
thought. Alternately i will open this as a Ximian/Gnome incident!
Comment 4 Jeremy Katz 2003-02-02 00:55:25 EST
Changing it would require major divergence from the upstream codebase which is
not something that we're looking to do.  And the implementation of the Trash
folder is very deliberately as a vfolder of deleted messages in all folders.
Comment 5 Thomas M Steenholdt 2003-02-02 01:29:03 EST
Explaination accepted! Thanks for taking a second look at the case!

Note You need to log in before you can comment on or make changes to this bug.