285474 - support delegated use of imap shared folders

Status: RESOLVED FIXED

(Thunderbird :: General, enhancement)

Description

[David :Bienvenu]

This is an enterprise feature, in which a user may delegate access to their
folders to someone else, typically an admin. The user gives the admin shared
access to their private folders. When the admin works with messages in the
shared folders, we want the From: address to be the users, not the admins. This
is controlled by a hidden pref, mail.imap.delegateOtherUsersFolders, defaulted
to false.

As part of this, we want to show the Sender: header when it's not the same as
the From: header, so that a recipient gets a hint that the e-mail was handled by
a delegate. This also helps with spoofing, with servers that fill in the sender:
header. That's controlled by the pref mailnews.headers.showSender, defaulted to
false (but we might want to change that default)

The custom identity method on folders could be used for things like
per-newsgroup identities.

Comment 1

[David :Bienvenu]

Attachment: proposed fix

Comment 2

[David :Bienvenu]

review ping - I think the sender header stuff we might want to turn on by
default...along with changing the places we display "Sender" to "From"

Comment 3

[Scott MacGregor]

Comment on attachment 176920 [details] [diff] [review]
proposed fix

1) if we show a sender header by default, then the changes to
msgHdrViewOverlay/xul.js will probably look a little different. Let's ditch the
pref and try it that way for a little bit on the trunk until I can get a better
feel for how often this comes up. 

2) If we are in the collapsed header view, I don't think we should be squeezing
this header in there. I'd ditch the collapsedsenderbox. The collapsed view is
intended for the bare miniumum of information (subject, date and from)

3) Why wouldn't we always want to set delegateOtherUsersFolders to true? Can we
lose the pref here and always conjure up the Sent By identity when working on a
delegated folder?

4) bump the IID in nsIMsgFolder

5) This customized identity is going to show up in our multiple identities list
from the account manager. Is that ok? And it looks like we create it and add it
to the account every time we call GetCustomIdentity? Is this going to lead to
lots of duplicate entries?

Comment 4

[David :Bienvenu]

Re 1, yeah, I think we probably should get rid of the pref.
Re 2, I'll do that.
Re 3, the behaviour turned on by this pref will be very surprising for normal
users of shared folders as opposed to users who are sharing folders specifically
to delegate, so I don't think we want this to be defaulted to on.

We only create the custom identity if we can't find it...but yeah, it will show
up  in the identity list (which is OK for users who want to turn this on for
delegation)

Comment 5

[David :Bienvenu]

Attachment: just the sender: header part of fix

Comment 6

[Scott MacGregor]

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

Comment 7

[[e-mail]]

(In reply to comment #5)
>Created an attachment (id=181385)
>just the sender: header part of fix
As a reminder that I mentioned on AIM that the line that got inadvertently
deleted was originally "var index = 0;" and belongs outside of the while loop.

Comment 8

[Scott MacGregor]

clearing nomination since the bug is already in the approved 1.1 milestone bucket.

Comment 9

[David :Bienvenu]

Comment on attachment 181385 [details] [diff] [review]
just the sender: header part of fix

this patch displays the sender header if it's different than the from header.
We'd like to get feedback on this.

Comment 10

[chris hofmann]

Comment on attachment 181385 [details] [diff] [review]
just the sender: header part of fix

a=chofmann

Comment 11

[David :Bienvenu]

the sender part of the patch has been checked in...

Comment 12

[David :Bienvenu]

moving the rest of this fix out past 1.1

Comment 13

[Ian Neal]

Attachment: headerValue instead of value patch v1.1

This patch:
* Changes header.value to header.headerValue which does actually get created
* Compares mailbox to mailbox rather than mailbox to headerValue

Comment 14

[Ian Neal]

Attachment: else if headerValue patch v1.1a (Checked in branch and trunk)

Changes since v1.1:
* Changed sender if statement to an else if

Comment 15

[Ian Neal]

Comment on attachment 198175 [details] [diff] [review]
else if headerValue patch v1.1a (Checked in branch and trunk)

Not sure if an sr= is required or not but might as well. I'm also guessing this
will be needed on the branch so requesting a= too as it makes the sender header
feature work as it should do. Patch should be fairly low risk.

Comment 16

[Scott MacGregor]

Comment on attachment 198175 [details] [diff] [review]
else if headerValue patch v1.1a (Checked in branch and trunk)

do we need similar changes in thunderbird?

Comment 17

[Ian Neal]

Comment on attachment 198175 [details] [diff] [review]
else if headerValue patch v1.1a (Checked in branch and trunk)

This is for Thunderbird btw, the mailnews equivalent is bug 308988

Checking in (trunk)
msgHdrViewOverlay.js;
new revision: 1.59; previous revision: 1.58
done
Checking in (branch)
msgHdrViewOverlay.js;
new revision: 1.56.2.1; previous revision: 1.56
done

Comment 18

[Ian Neal]

Additional changes were made in the patch on bug 308988 for trunk to really fix sender being shown if it is different to from

Comment 19

[Mike Cowperthwaite]

Any reason this bug should remain open?

Comment 20

[David :Bienvenu]

marking fixed - mainly by the patches in  bug 308988

Comment 21

[David :Bienvenu]

Attachment: part not checked in

this adds support for per-folder custom identity - and the automatic creation thereof for other user's imap folders, when a special pref is set.