MozillaZine

TB Delete Attachment Extension ( created !)

Talk about add-ons and extension development.
TechFan
 
Posts: 88
Joined: September 6th, 2003, 10:03 pm

Post Posted May 21st, 2004, 1:07 am

Seems to be working well. . .will definitely make use of this extension, even if it means I have to copy the mail messages locally first. . .:-)

I can see how doing this on IMAP could be a challenge. . .since it would require editing within each message and not re-creating the folder, totally different approach.

Thanks for this tool. So far, everything has been working as expected.

jimmy73
 
Posts: 47
Joined: May 1st, 2004, 1:25 am

Post Posted May 21st, 2004, 9:30 am

Hi!

Version 1.0.1 works fine! You have come really far, ausdilecce! Congratulations and thank you!!

Some comments:

ausdilecce wrote:We now have the ability to :
1) Delete all attachments ( the cause of all this ! ) -- you can select from menu or right click a message or right click attachment box

Menu in the attachemnt box works fine!
Right click into the message -> del. all att. or Menu -> del. all att. does *nothing*. Tried with 1 pdf and 5 jpgs attachements. Result: zero. But it works fine in the attachement box!
Deleting seems not to work at all with attached emls.

ausdilecce wrote:3) ZAP all attachments ( this will leave the message with NO TRACE of any attachments -- except text and rfc822 )
...right click attachment box n choose 'ZAP All Attachments'

It would by 110% if you could add the menu-point "zap attachement(s)". That would be great!

ausdilecce wrote:4) 'Add message Attachment to this folder' ( will add a message attachment as a real message in the current folder )
...is a choice on right click menu of attachment box

Did I get this right? This works only with en eml-file?!

ausdilecce wrote:5) Import and email file ( ability to choose a .eml file and import it into the current folder )
...right click one any message pane n choose .. 'import Eml File'

That's so great this is possible now in Thunderbird! YIPIIEE!! 110% would be, if one could import more eml-files at once! I often have 10 or 20 emls attached in an email. It would be great if I could import them with just a few clicks.

Thanx again! This has become the most important extension for me!!

Jimmy73

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 21st, 2004, 9:51 am

jimmy73 wrote:Menu in the attachemnt box works fine!
Right click into the message -> del. all att. or Menu -> del. all att. does *nothing*. Tried with 1 pdf and 5 jpgs attachements. Result: zero. But it works fine in the attachement box!


I will have a look at why that popup menu option does not work

jimmy73 wrote:Deleting seems not to work at all with attached emls.


You are correct, only non-text attachments are zapped or deleted
.. so rfc822 and html and text content-types are preserved, everything else can be zapped or deleted

jimmy73 wrote:It would by 110% if you could add the menu-point "zap attachement(s)". That would be great!


Ok, don't see why not

jimmy73 wrote:Did I get this right? This works only with en eml-file?!


This only makes (one) attached rfc822 ( a message attached to a message ) a 'real' message ( makes it a message in the thread pane )

Right Click on message pane and choose 'Import Eml File' actually allows you to take a 'saved' message (a file with a .eml extension )
and make it a 'real' message ( makes it a message in the thread pane )

NOTE : I would love to hear how/if this works on Macs

jimmy73 wrote:That's so great this is possible now in Thunderbird! YIPIIEE!! 110% would be, if one could import more eml-files at once! I often have 10 or 20 emls attached in an email. It would be great if I could import them with just a few clicks.


You MUST be a manager or something (the '110% would be' thing :wink: )
Doing multi imports is tough. And my brain hurts at the moment. What you are describing will come.. later rather than sooner.

jimmy73 wrote:Thanx again! This has become the most important extension for me!!


Glad you like it. Some of it has been fun ( and some a chore ) But that is life, right ?

Cheers

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 21st, 2004, 5:26 pm

I have thought better of it and changed the version number to 0.4.0, ( don't know why I chose 1.0.1, must have needed caffeine)

To all those who downloaded version 1.0.1 -- there is no difference between 0.4.0 and 1.0.1 except for version number

Sorry for the confusion

Cheers

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 21st, 2004, 5:31 pm

TriEnt wrote:Two issues (for the 0.2.1 version but they probably also apply to the new one):

1. Bug: when deleting an attachment, during the process (probably when the MSF is deleted) the folder column sorting preferences are lost. For example, I like to keep all my folders sorted by date in descending order (as opposed to the default ascending mode). When I use the extension I get the layout reset to default. Can you "save" the folder view preferences & restore them when the process is complete?


In order to do that, I would need to do alot of copying and saving, throwing messages into temp folders back and forth. Not very performance oriented. ( I guess I could have a pref for it but .... )

TriEnt wrote:2. (Slightly offtopic but maybe less now, now that the extension is doing more than originally planned): is it possible to add another feature: replacing an attachment (eg the original file with an archived version)? I'd like for example that, if somebody sends me a big Word document to be able to save the attachment, RAR/ZIP it, and then reattach it to the document so that it takes less space but still preserve it in the message?


NO. this would be a monster of a job, for a tiny audience ( at least I think its a tiny audience. If you could collect some support, I might be swayed )
Still.. its a b*tch of a job.

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 23rd, 2004, 11:37 pm

Extension updated ( again ! can't leave well enough alone I guess )

Changes include:
1) added 'Import Saved Message' to File menu
2) added 'ZAP All Attachments' to tools menu
3) added 'ZAP All Attachments' to message right click menu
4) added rfc2047 support ( for attachment names that look like this :
....<code> name="=?ISO-8859-1?Q?Doc_types_for_HPF=2Exls?="</code>
5) added retention of folder column sort and view style ( it used to revert to sorted by descending date, and view all, non threaded )
6) added timer mechanism so the delete attachment procedure ( on messages with many large attachments )does not appear to freeze TB
7) progress bar actually works now cuz TB can process the screen paint request
8 ) added status message to tell user approx how much of the message has been processed ( as a percentage )

XPI is released ( on my site )
Working on ZAP one or many messages

Anything else ?

TriEnt

User avatar
 
Posts: 52
Joined: February 26th, 2004, 11:38 pm
Location: Bucharest, RO

Post Posted May 24th, 2004, 12:04 am

Hi ausdilecce,

What's the pref setting for the attachment file name (the %s thing)? Are there any other "tunable" settings?

Thanks!

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 24th, 2004, 12:51 am

Add this pref to your prefs.js file

<code>user_pref("delattach.erasureStr", "*killd* %s");</code>

the %s bit will get replaced by the filename

these are two more prefs that you can set

user_pref("delattach.debug", true); EDIT: I had inadvertently put false instead of true, fixed now
this shows you (numerous ) messages while attachment tools is doing its thing

user_pref("delattach.delAttchHdrStr", "Attachment was deleted, details are: ");
this pref sets what the message will be above the text part of the attachment details
Last edited by Old Ausdilecce on May 24th, 2004, 5:20 am, edited 1 time in total.

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 24th, 2004, 1:28 am

Not gonna release it but just managed to allow a user to select multiple eml files to import
....( as opposed to just being able to import them one at a time)

TriEnt

User avatar
 
Posts: 52
Joined: February 26th, 2004, 11:38 pm
Location: Bucharest, RO

Post Posted May 24th, 2004, 3:44 am

ausdilecce wrote:user_pref("delattach.debug", false);
this shows you (numerous ) messages while attachment tools is doing its thing


Shouldn't this read "true" instead of "false"? I mean, if you're enabling debugging, the pref should be "debug=true" ;-)

ausdilecce wrote:user_pref("delattach.delAttchHdrStr", "Attachment was deleted, details are: ");
this pref sets what the message will be above the text part of the attachment details


Can you add a pref to fully disable writing the details into the dummy file? The reason I'm asking this is because, given something like this:

Attachment was deleted, details are:
Content_Type: application/octet-stream;
name="DDL.REM.rar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="DDL.REM.rar"


It doesn't provide much information because:
1) the dummy file name is "DDL.REM.rar (erased)" so the original file name is already there, and
2) the content type is obviously application/octet-stream because this is a RAR archive; if it were a .txt file, the content type would be plaintext and so on.. you can easily guess this from the file extension (on Windows at least; on Linux people are too smart to need it anyway! ;-) ). What I'm trying to say is that this doesn't provide that much added value.

On the other hand, what I'd rather find REALLY useful would be to have the original file size saved in the attachment.


To sum up, what do you think of this: add a new pref, delattach.AttachFileBody with three possible values:
- (unset): the default text will be used (the way it works now)
- "": the dummy file name will be EMPTY
- text e.g. "Attachment was deleted, details are:\nOriginal size: $size\n$content-type\n$content-transfer\n$content-dispo\n"

so basically whenever the pref would contain one of the tokens ($size, $content-type, $content-transfer, $content-dispo) it would replace it with the appropriate information.


Even if this is hard to implement, I'd still vote both hands up for including the size. This can be really handy when, for example, you want to check if the file you have on disk matches (size speaking) what was attached to the e-mail. If they don't, it's a very clear indication that you have two versions of the same file. Out of which, btw, one of them is lost because the attachment was zapped. But that's another issue (off-topic but what about including a warning: "Are you REALLY REALLY sure you want to delete the attachment(s)?!")...

AlexIhrig
 
Posts: 239
Joined: May 23rd, 2003, 5:47 am
Location: Germany

Post Posted May 24th, 2004, 4:01 am

Hi Frank,

it would be great to have the strings out of your JS files in a *.properties file. So I would be able to translate the extension without hacking your JS files....

Regards
Alex Ihrig
Thunderbird DE
Thunderbird Mail DE: http://www.thunderbird-mail.de
Enigmail OpenPGP [de]: http://enigmail.thunderbird-mail.de/

Old Ausdilecce
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted May 24th, 2004, 5:17 am

TriEnt wrote:
ausdilecce wrote:user_pref("delattach.debug", false);
this shows you (numerous ) messages while attachment tools is doing its thing


Shouldn't this read "true" instead of "false"? I mean, if you're enabling debugging, the pref should be "debug=true" ;-)


Doh! yea sorry.

TriEnt wrote:
ausdilecce wrote:user_pref("delattach.delAttchHdrStr", "Attachment was deleted, details are: ");
this pref sets what the message will be above the text part of the attachment details


Can you add a pref to fully disable writing the details into the dummy file? The reason I'm asking this is because, given something like this:

Attachment was deleted, details are:
Content_Type: application/octet-stream;
name="DDL.REM.rar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="DDL.REM.rar"


Well, this info is already present in the message, its just that now I am converting the info into text/plain so you don't get a picture placeholder on images or some other artifact in the message pane where the attachment was supposed to go (if you are viewing attachments in-line)

TriEnt wrote:It doesn't provide much information because:
1) the dummy file name is "DDL.REM.rar (erased)" so the original file name is already there, and


True, but it was 'messed with' , meaning my extension replaced the name with something else ( it is possible to have the pref not have a %s you know )

TriEnt wrote:2) the content type is obviously application/octet-stream because this is a RAR archive; if it were a .txt file, the content type would be plaintext and so on.. you can easily guess this from the file extension (on Windows at least; on Linux people are too smart to need it anyway! ;-) ). What I'm trying to say is that this doesn't provide that much added value.


Not really, some mail packages ( like OE ) constantly dictate the wrong content-types and TB actually checks to make sure the content type is what it should be. As I said before, I am not providing anything new except for the 'Attachment was deleted, details are' pref string and changing the attachment header to plaintext so it can be read when attachments are displayed in-line.

TriEnt wrote:On the other hand, what I'd rather find REALLY useful would be to have the original file size saved in the attachment.


I looked into this. It seems that the only way for me to find out what the file size would be if the attachment was saved is to:
1) actually save the attachment
2) read the filesize
3) delete the file.

Ugg, sounds very messy


TriEnt wrote:To sum up, what do you think of this: add a new pref, delattach.AttachFileBody with three possible values:
- (unset): the default text will be used (the way it works now)
- "": the dummy file name will be EMPTY
- text e.g. "Attachment was deleted, details are:\nOriginal size: $size\n$content-type\n$content-transfer\n$content-dispo\n"

so basically whenever the pref would contain one of the tokens ($size, $content-type, $content-transfer, $content-dispo) it would replace it with the appropriate information.


This is starting to sound like feature bloat.

TriEnt wrote:Even if this is hard to implement, I'd still vote both hands up for including the size. This can be really handy when, for example, you want to check if the file you have on disk matches (size speaking) what was attached to the e-mail. If they don't, it's a very clear indication that you have two versions of the same file.


Look, if one cannot keep track of what files they saved and when, NO amount of coding will help them from themselves.

TriEnt wrote:Out of which, btw, one of them is lost because the attachment was zapped. But that's another issue (off-topic but what about including a warning: "Are you REALLY REALLY sure you want to delete the attachment(s)?!")...


That is precisely why I throw the original in the trash. Just in case you really screwed up. BTW, a new copy is saved to the trash on *each* operation. Meaning, if you deleted one of 10 attachments from one message, then later, deleted another one of the attachments from that same message, there will be two copies of that message in your trash, one with all 10, and another copy with 9 attachments + the stripped attachment.



FYI to everyone, once I do the following, I am gonna call this extension DONE ( unless someone can come up with a really needed feature )
1) zap one or many attachments.... ( this was completed 20 mins ago )
2) import many eml files.......... ( this was completed 2 hrs ago )
3) make one or many rfc822 attachments 'real' ( not done yet )
4) Localize it ( not done yet )

TriEnt

User avatar
 
Posts: 52
Joined: February 26th, 2004, 11:38 pm
Location: Bucharest, RO

Post Posted May 24th, 2004, 5:56 am

ausdilecce wrote:
TriEnt wrote:On the other hand, what I'd rather find REALLY useful would be to have the original file size saved in the attachment.


I looked into this. It seems that the only way for me to find out what the file size would be if the attachment was saved is to:
1) actually save the attachment
2) read the filesize
3) delete the file.

Ugg, sounds very messy


Hmm.. what about this: next to delete/zap, add a "detach" option to do save & delete in sequence. That way you can also get the filesize during the process. Bloatware? You bet. But it already surpassed the original purpose (when you added the .EML processing feature).

ausdilecce wrote:
TriEnt wrote:To sum up, what do you think of this: add a new pref, delattach.AttachFileBody with three possible values:
- (unset): the default text will be used (the way it works now)
- "": the dummy file name will be EMPTY
- text e.g. "Attachment was deleted, details are:\nOriginal size: $size\n$content-type\n$content-transfer\n$content-dispo\n"

so basically whenever the pref would contain one of the tokens ($size, $content-type, $content-transfer, $content-dispo) it would replace it with the appropriate information.


This is starting to sound like feature bloat.


That's the very reason for which I'm using Mozilla. Nice and useful bloatware :-D

Cheers
L

TriEnt

User avatar
 
Posts: 52
Joined: February 26th, 2004, 11:38 pm
Location: Bucharest, RO

Post Posted May 24th, 2004, 5:57 am

ausdilecce wrote:
TriEnt wrote:On the other hand, what I'd rather find REALLY useful would be to have the original file size saved in the attachment.


I looked into this. It seems that the only way for me to find out what the file size would be if the attachment was saved is to:
1) actually save the attachment
2) read the filesize
3) delete the file.

Ugg, sounds very messy


Hmm.. what about this: next to delete/zap, add a "detach" option to do save & delete in sequence. That way you can also get the filesize during the process. Bloatware? You bet. But it already surpassed the original purpose (when you added the .EML processing feature).

ausdilecce wrote:
TriEnt wrote:To sum up, what do you think of this: add a new pref, delattach.AttachFileBody with three possible values:
- (unset): the default text will be used (the way it works now)
- "": the dummy file name will be EMPTY
- text e.g. "Attachment was deleted, details are:\nOriginal size: $size\n$content-type\n$content-transfer\n$content-dispo\n"

so basically whenever the pref would contain one of the tokens ($size, $content-type, $content-transfer, $content-dispo) it would replace it with the appropriate information.


This is starting to sound like feature bloat.


That's the very reason for which I'm using Mozilla. Nice and useful bloatware :-D

Cheers
L

TechFan
 
Posts: 88
Joined: September 6th, 2003, 10:03 pm

Post Posted May 24th, 2004, 7:35 am

Looking better and better. . .

Just in the amazingly slim chance that it might be considered. . .IMAP support would be great. ;-)

Also, something that might be related. . .striping out all non-text MIME parts / make a message text only.

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 2 guests