Bug 80995 - IMAP: attachment icons not immediately displayed
Summary: IMAP: attachment icons not immediately displayed
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail
Classification: Applications
Component: IMAP (show other bugs)
Version: 1.9.9
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
: 155266 209087 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-05-05 22:37 UTC by Ferdinand Gassauer
Modified: 2015-04-13 01:42 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ferdinand Gassauer 2004-05-05 22:37:26 UTC
Version:           1.6.52 (using KDE 3.2.2, compiled sources)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:          Linux (i686) release 2.4.21-215-default

the new icons for attachments are IMHO not displayed for "old" messages. 
After clicking on a messageheader the icon is displayed

(settings: download attachments on demand=yes)

cu ferdinand
Comment 1 Ferdinand Gassauer 2004-05-05 22:39:07 UTC
at least for IMAP folders !!
Comment 2 Carsten Burghardt 2004-05-06 00:13:30 UTC
To check the attachment state for old messages would mean to load all messages completely once which is not acceptable.
Comment 3 Ferdinand Gassauer 2004-05-06 06:21:56 UTC
On Thursday 06 May 2004 00:13, Carsten Burghardt wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=80995
> burghardt kde org changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- Status|NEW                         |RESOLVED
>          Resolution|                            |WONTFIX
>
>
>
> ------- Additional Comments From burghardt kde org  2004-05-06 00:13
> ------- To check the attachment state for old messages would mean to load
> all messages completely once which is not acceptable.
Hmm!
what's the alternative ?
having inconsistent data (IMHO not acceptable for business use)
or   
manually delete the local imap information to trigger a reload.
Comment 4 Carsten Burghardt 2004-05-06 10:05:42 UTC
The data is not inconsistent. We just haven't interpreted it.
The attachment icon is only for information so I don't think that it is a problem that it is only updated when you once clicked on the message.
Even deleting the local cache doesn't help as we only load the headers and they don't tell you if the message has an attachment.
Comment 5 Ferdinand Gassauer 2004-05-06 11:01:59 UTC
no user will understand this behaviour.

can we get a function - "click all headers" which is executed once the new 
release gets installed.
Comment 6 Andreas Gungl 2004-05-06 14:31:53 UTC
Ferdinand Gassauer wrote:
> no user will understand this behaviour.
> 
> can we get a function - "click all headers" which is executed once the new 
> release gets installed.

Perhaps it's worth a thought: We're (optionally) showing question marks 
if the signatur/encryption state is not yet known for a message. Perhaps 
we can use a special icon (somehow a question mark too) for not 
completely downloaded messages / downloaded headers?
This would indicate clearly the state to the user. However I don't know 
how difficult it is to implement that.

Comment 7 Don Sanders 2004-05-07 03:43:21 UTC
FWIW I agree with Carsten's statements.

Comment 8 Ferdinand Gassauer 2004-05-07 07:57:47 UTC
So does it mean that one has to download the messages to know if there is an attachment.
if so - this should also be stated near the "load attachement on demand" option.

BTW are the messages + attachments cached locally - I have the impression that not.

There are 2 things I am concerned off
1) not showing the user,that there is an attachment (because kmail does not know/check it
2) useless traffic, because i do not need all attachments downloaded.
Comment 9 Carsten Burghardt 2004-05-07 11:54:50 UTC
You always have to select the message once to analyse if it has attachments.
Without load-on-demand the message is loaded completely. With lod we only load the headers of the attachments to get this information.
As I already said: we only cache (=write to disk) the headers.
The alternative would be to show (as Andreas already stated) a question mark or similar as long as we don't know. This would be possible but I personally would not like this as there is already a lot of information shown and "yet another question mark" would clutter this even more.

Comment 10 Ferdinand Gassauer 2004-05-07 12:17:14 UTC
Hmm! 
I can not follow you completely
We apparently have 3 possibilities
- load headers (check mail in folder/imap)
- load message-text (click on message-header) 
-- loads message-text with/without attachments (option load attachment on 
demand)

IMHO an option "preload message-text" would do it, eventually combined with a 
a limit of a maximal text size

If I understand it correctly also for deleting the message I have to click it 
and hence download it before actually deleting it
Comment 11 Andreas Gungl 2004-05-07 20:53:56 UTC
On Freitag, 7. Mai 2004 11:54, Carsten Burghardt wrote:
> The alternative would be to show (as Andreas already stated) a question
> mark or similar as long as we don't know. This would be possible but I
> personally would not like this as there is already a lot of information
> shown and "yet another question mark" would clutter this even more.

Yes, a question mark would not fit. I thought about it again. I think, it 
would be a usefull information for the user that only the header is 
downloaded and known. So the body is still on the server and information 
about attachments is not available.
What about a diagonal separation of the current message icon (left lower to 
right upper corner) where the upper part is colored as is while the lower 
part is showing less color (like alphablended). Well, I'm no artist, but 
this is what I would use as a first try.

Comment 12 Ferdinand Gassauer 2004-05-08 01:02:41 UTC
Please don't assume that the user understands what happens here. 
IMHO an application has to privide a consitent easy to understand information. 
No user will understand why he/she has to click a header to see if there is an attachment, even this is necessary because of some Specs.
Other way round. If I have to click on a header to see if there is an attachemnt I want the computer to make the click for me.
Comment 13 Thomas McGuire 2008-01-12 16:37:42 UTC
*** Bug 155266 has been marked as a duplicate of this bug. ***
Comment 14 Thorsten Staerk 2008-01-12 20:57:22 UTC
It is not acceptable that this is left as wontfix. E.g. if I want to find out all my attachments in my mail account, I make a search that lists all mails and then I sort by the attachment column. This will seem to work to the normal user. The user will have no chance to see that some of the attachments he has are missing.
Comment 15 Salvatore Brigaglia 2008-11-09 12:38:13 UTC
i think the problem is somewhat resolved since you can find all messages with attachments using the "edit -> find messages" function wich download all you messages from server to look into them (wich can be really slow). Apparently there's no other way to achieve this, only devs can know.
(bug triage day 09 november 2008) opensourcecat.
Comment 16 Viorel Tabara 2009-01-12 17:56:22 UTC
<quote>
tstaerk  2008-01-12 20:57:22
It is not acceptable that this is left as wontfix
</quote>

As much as I want a feature I realize that I have never submitted a patch nor do I have the knowledge to do it - for that reason I find acceptable if the developers decide that my request is not going to be fixed. Having such a good environment for free should not be taken for granted. You can get the source and patch the code if you really need that feature - then post the patch and eventually it will make it into the mainstream. Alternatively, vote for the bug and get others to do it.
Comment 17 Tim Holy 2009-01-18 22:48:36 UTC
FYI this is relevant for more than IMAP---it holds for POP too. The main problem is that in the absence of an attachment icon, the implication is that there _isn't_ an associated attachment; there is no way for the user to distinguish between "not enough information" and "this message doesn't have an attachment."

It seems that the old (KDE3) Kontact must have maintained some type of database that stored information about the status of each message (attachment, reply/forward, etc). Wouldn't it be possible to migrate that database when the user upgrades to KDE4? Presumably it's too late for those of us who have already upgraded?

I for one would appreciate a script that went through all the messages once and fixed their status. I even helped write such a script for a different purpose (migrating UTC->localized times in korganizer, see bug 165212), but in this case I don't yet know enough about how this information is stored to help out.
Comment 18 Ferdinand Gassauer 2009-01-19 10:20:13 UTC
It is a BIG usability issue !!!
Comment 19 Björn Ruberg 2010-03-06 15:24:42 UTC
*** Bug 209087 has been marked as a duplicate of this bug. ***
Comment 20 chris-walter 2011-12-21 15:16:56 UTC
I also noticed this issue by accident because some of my mails did not show an attachement-symbol even though there was an attachement.

This really is a big problem because I do a lot of searching for attachements (invoices etc.). When this search is not giving any reliable results anymore, than at least remove this feature (searching for attachements) completely. Because otherwise the user is left completely in the trust that all the results he obtained are true, which is NOT the case.

Besides, at my kmail the attachement icon doesnt even appear when I click on the mails. It just shows that there is no attachement, even if there is...
Comment 21 Rob Kemp 2012-01-11 12:24:35 UTC
Just came back to Kmail after a long absence. I don't want to have to go back to Thunderbird because of this, but ...
Comment 22 Ezio Vergine 2012-02-05 19:59:06 UTC
Same issue here.
kmail Version 4.8.0. kubuntu 11.10.
Comment 23 Laurent Montel 2015-04-12 10:13:39 UTC
Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.
Comment 24 Alexander Potashev 2015-04-13 01:42:35 UTC
KMail2 had similar bug #286692, it's already fixed.