Comment 1 Dirk-Jan C. Binnema 2007-12-21 10:08:17 UTC

*** Bug 2603 has been marked as a duplicate of this bug. ***

Comment 2 Tim Samoff 2007-12-21 16:44:33 UTC

While this may be a "new" feature, the functionality is, in fact a "bug" --
even though it's not supported yet. Therefore, should the priority be set
higher than Low?

Comment 3 Dirk-Jan C. Binnema 2007-12-21 17:14:39 UTC

well, one man's bug is another man's feature i guess.
i agree it would be a nice feature.

i don't think that what we put here as 'priority' will make much 
of a difference though - feel free to update it.

Comment 4 Tim Samoff 2007-12-21 17:33:05 UTC

I agree that this might be a feature for something like POP (or otherwise), but
the whole point of IMAP is to be able to keep mail synced on a a centralized
server, no?

(The poor disrespected Priority level has been changed.) :p

*** This bug has been confirmed by popular vote. ***

Comment 6 Andre Klapper 2008-06-16 15:51:11 UTC

priority medium - I agree this would be very nice and useful to have fixed, but
it's not the highest priority (and it makes it easier for me to track those
really high priority issues).

Comment 7 Quim Gil 2008-12-29 13:15:28 UTC

This is not planned for Fremantle. Setting target milestone to Harmattan,
although it is not confirmed yet. 

The request makes sense but its implementation is complex and we prefer to
concentrate on other bugs/features first.

Comment 8 Quim Gil 2009-09-26 00:18:26 UTC

This feature request is curently the most popular in the Brainstorm:
http://maemo.org/community/brainstorm/view/keep_sent_and_drafts_on_imap_server/?solution=official_email_client

In order to avoid duplications I will resolve it here as Invalid. Not because
is not a valid request but because it's the less wrong resolution available.

*** Bug 6280 has been marked as a duplicate of this bug. ***

*** Bug 6425 has been marked as a duplicate of this bug. ***

Comment 11 Andre Klapper 2009-12-06 16:30:56 UTC

*** Bug 6618 has been marked as a duplicate of this bug. ***

*** Bug 6701 has been marked as a duplicate of this bug. ***

Comment 13 Andre Klapper 2010-01-07 12:32:47 UTC

*** Bug 7730 has been marked as a duplicate of this bug. ***

*** Bug 8266 has been marked as a duplicate of this bug. ***

Reopening to resolve as MOVED.

...which apparently I can't do.  I only have "FIXED", "INVALID", "WORKSFORME",
and "WONTFIX", not the new "MOVED" resolution.  Argh.

Comment 17 Andre Klapper 2010-01-26 13:46:35 UTC

The scope of bugs.maemo.org are bugs and only very specific and no-brainer
enhancement requests. This report contains a feature request that is too
generic for bugs.maemo.org. Please post this problem and propose your
solution in Maemo Brainstorm instead:
  http://maemo.org/community/brainstorm/

More information: http://wiki.maemo.org/Maemo_brainstorm

Comment 18 Andre Klapper 2010-02-01 18:38:44 UTC

*** Bug 8751 has been marked as a duplicate of this bug. ***

*** Bug 8976 has been marked as a duplicate of this bug. ***

*** Bug 9233 has been marked as a duplicate of this bug. ***

I would like to reopen this since it is the #2 most frequently reported bug and
the brainstorm had a deafeningly clear outcome (as expected, since this *is* a
specific request).  Any objections?

(In reply to comment #21)
> I would like to reopen this since it is the #2 most frequently reported bug and
> the brainstorm had a deafeningly clear outcome (as expected, since this *is* a
> specific request).  Any objections?

I'm supportive of reopening, but don't appear to have permission to.  From the
initial filing, this has always been a specific and well-articulated feature
request aimed at achieving parity with other well-established email-clients. 
It doesn't need the kind of "out-of-the-box" thinking about solutions that
brainstorm brings, it just needs bodies to implement it.

*** Bug 9464 has been marked as a duplicate of this bug. ***

The IMAP email Achilles Heel.  It's not a feature, it's a necessity.

(In reply to comment #7)
> The request makes sense but its implementation is complex and we prefer to
> concentrate on other bugs/features first.

Hi Quim, I'm curious to hear what you (and the community, of course!) think of
the minimalistic approach I describe in solution 13 in that brainstorm page.

@mariotomo: Why add an option to BCC (which sends a copy of outgoing mail to
the remote inbox (via the SMTP server) , not the remote sent mail folder) when
it should Just Work and put a copy in remote sent mail by itself ?
This is how *every other IMAP client in the world* works, and also has the
least surprise and greatest ease of use.

(In reply to comment #26)
> @mariotomo: Why add an option to BCC (which sends a copy of outgoing mail to
> the remote inbox (via the SMTP server), not the remote sent mail folder) 

fair question.  see below...

> when
> it should Just Work and put a copy in remote sent mail by itself ?
> This is how *every other IMAP client in the world* works, and also has the
> least surprise and greatest ease of use.

I've looked at Thunderbird, it offers both options.  Also Claws-mail offers a
bcc field in the 'Sending' tab, and a copy to folder in the 'Advanced' tab.

in Thunderbird (definitely not a "modest" program) the option "place a copy in
the 'Sent' folder" is associated to a pulldown menu for choosing an alternative
folder where to copy the email.  that pulldown menu can be populated if you are
online, which is not guaranteed to be the case on a mobile thing like the N900
(it is most definitely not the case for me 95% of the time when I'm on
holiday).

reading the sources and thinking of the possible implementations, "Just Work"
does not admit one unique interpretation.  that's why there's a brainstorm page
about this.

the other option is of straightforward implementation and quite fit for
something called "modest", imho.

so back to your question: why add this 'bcc' and what do I think of the fact
that the email goes into the Inbox and not the Sent folder?  

because this is easy to implement, and because it satisfies the requirement
"hold emails regarding account A within account A".

but I'm afraid we're brainstorming here...

(In reply to comment #27)
> so back to your question: why add this 'bcc' [...]?  
> 
> because this is easy to implement, and because it satisfies the requirement
> "hold emails regarding account A within account A".
> 

oh, yes, ... and because "every other IMAP client [we know of] in the world"
offer (also) this option.

@mariotomo:
The use of 'sent mail' as a default is standard. 
It happens to be configurable but most users expect sent mail to Just Work and
appear in any IMAP client.
I don't follow your comment about 'pulldown menu can be populated if you are
online, which is not guaranteed' because putting a copy in 'sent mail' implies
you are online and sending email. 

'satisfies the requirement "hold emails regarding account A within account A".'
isn't the problem; the problem is that for some reason 'sent mail' folder is
excluded from the sync. process that applies to the other IMAP folders.

And, in fact, I think users would find it more confusing (no matter how easy or
hard it is for us to write the code) to have a copy of sent mail appear in
their inbox (this never normally happens), rather than either no where (as now)
or sent mail (as wanted).

(In reply to comment #29)
> And, in fact, I think users would find it more confusing (no matter how easy or
> hard it is for us to write the code) to have a copy of sent mail appear in
> their inbox (this never normally happens), rather than either no where (as now)
> or sent mail (as wanted).

Actually, I hate it showing up in Sent. Thunderbird can be configured to place
it in the same folder as the mail you replied to (when replying of course),
which, in the case of incoming mail, is typically the Inbox.
If and when this bug is getting fixed, it would certainly be nice to have this
option in Modest too.

(In reply to comment #27)
> because this is easy to implement, and because it satisfies the requirement
> "hold emails regarding account A within account A".
please, do not think of satisfying this requirement, this is incorrect
approach.
and please don't offer solutions of touching your nose while standing on one
arm and flapping with your feet.
most users of IMAP want FOLDERS, just that, so I connect from my computer, n900
and webmail and see all the same. Who doesn't need it uses POP3. And stop with
servers side solutions, not all of users can/know/want to mess with sieve
scripts.

(In reply to comment #29)
> @mariotomo:
> [...] most users expect sent mail to Just Work and
> appear in any IMAP client.

maybe.  personally, I prefer my mail to be in one mailbox (the Inbox folder) so
that I can follow the threads.  given this use, you see I would be more than
satisfied with the bcc field (and would not be happy with the "copy to Sent").

> I don't follow your comment about 'pulldown menu can be populated if you are
> online, which is not guaranteed' because putting a copy in 'sent mail' implies
> you are online and sending email. 

I mean: obviously you're online while sending mail, but you're not guaranteed
to be online while you're configuring it (or editing the configuration).  while
you're in that screen and if you want (as I would want) to choose an other
folder rather than the default 'Sent', the N900 would need to retrieve the
folder list from the server.  I'm not sure, but I'm afraid that this makes the
implementation of this option "difficult".  maybe part of the explanation why
it is taking so long to implement it.

> the problem is that for some reason 'sent mail' folder is
> excluded from the sync. process that applies to the other IMAP folders.

?  wait, I don't get this.  ...  mumble ... mumble ...  ah, you mean the three
'Drafts', 'Outbox' and 'Sent' folders following 'Inbox'?  none of them is
synchronized with the IMAP server, is it?  only the Inbox is, all others stay
local to the N900 and are shared among accounts (quite confusing at first!). 
yes, "some reason", I would guess: network traffic.  it looks like a design
choice/limitation.

anyway: the two options (copy and bcc) are not exclusive of each other.  the
two email clients I checked offer both things.  'mutt' also has both options
(and many more, obviously).

(In reply to comment #32)
> anyway: the two options (copy and bcc) are not exclusive of each other.  the
> two email clients I checked offer both things.  'mutt' also has both options
> (and many more, obviously).
@mariotomo
mutt. mutt options. Okay. sorry for the previous post, such solutions you offer
would rather seem natural to you.

I've opened a different bug report regarding the (not implemented) 'bcc'
option.  it's number 9747.

no BCC is not a solution and this should have been fixed a long time ago. If
Nokia wants to attract any traveling business customer then they should ship
their products with a functioning E-Mail client.

Comment 36 Andre Klapper 2010-06-02 13:49:24 UTC

*** Bug 10426 has been marked as a duplicate of this bug. ***

Comment 37 Andre Klapper 2010-06-04 14:49:07 UTC

*** Bug 10553 has been marked as a duplicate of this bug. ***

> Comment  #7 from Quim Gil   (Nokia)   2008-12-29 13:15:28 GMT+3 [reply]
> 
> This is not planned for Fremantle. Setting target milestone to Harmattan,
> although it is not confirmed yet. 
> 
> The request makes sense but its implementation is complex and we prefer to
> concentrate on other bugs/features first.

The full implementation is probably complex, but a simple patch is possible.
Indeed, modest can store sent mails in the local sent folder. Modest, can also
move a message from a folder to another. So, an option saying "Move messages
from sent to XXX remote folder (from time to time, whenever possible)" will
only use implemented features and solve two problems in a row:
- we can choose where sent messages are (eventually) stored,
- there is no issues even if the smtp server is available and the imap server
not. 

I hope this idea helps,

Carlos

Comment 39 Andre Klapper 2010-11-29 20:30:05 UTC

For your interest, the internal User Interface specification for Email in
Harmattan (the software version after Maemo5) currently states:

"Messages in sent folder are synchronized with the server, if used mail server
protocol allows it." and "Messages in Drafts folder are synchronized with the
server, if used mail server protocol allows it."

Comment 40 Andre Klapper 2011-01-30 20:20:22 UTC

Josh: Can you explain why you added the community-fremantle keyword, please?
TIA

(In reply to comment #40)
> Josh: Can you explain why you added the community-fremantle keyword, please?
> TIA

You already stated that this issue would get resolved for Harmattan, which
suggests that an upstream fix either exists or will exist.  At that point,
writing/backporting that fix to Fremantle seemed like an ideal addition to the
community SSU, so I added the community-fremantle keyword to mark it as such.

Comment 42 Andre Klapper 2011-01-31 15:46:19 UTC

(In reply to comment #41)
> You already stated that this issue would get resolved for Harmattan, which
> suggests that an upstream fix either exists or will exist.  At that point,
> writing/backporting that fix to Fremantle seemed like an ideal addition

There is no public or isolated patch available and I don't expect the code to
be similar to Maemo5 code, hence sounds like wrong assumptions currently. :-/

Comment 43 Andre Klapper 2012-03-24 11:38:37 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )