123093 - Implement the folder privileges button to share folder and set permissions

Status: VERIFIED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Karen Huang]

Used 02-01-06-trunk build

Implement the folder privileges button to share folder and set permissions

We have "Sharing Tab of Imap Folder Properties" and the "folder privileges 
button" UI now, we should implement the folder privileges button to share folder 
and set permissions for IMAP Shared Folders

Setup Info: Need to access an IMAP account with Server Admin enable for 
accessing Folder privilege.

1) Login to an IMAP mail account 
2) Righ mouse clieck for accessing "Properties"
3) Select Sharing Tab
4) Select Privileges button
5) Actual Results: Blank

Expected results: Should prompt user & password login for accessing IMAP share 
folder and set folder permissions

Comment 1

[Karen Huang]

Oops! should be 
2) Right mouse click for accessing "Properties"

Comment 2

[Karen Huang]

Nominating nsbeta1

Comment 3

[David :Bienvenu]

I've actually implemented what 4.x did - did you diverge from 4.x on purpose,
Jennifer? For example, 4.x would say "This is a personal folder. It has been/is
not shared". Is it worth my going back and changing it all?

Comment 4

[jglick]

No, not worth changing. They have the same information, I just used "Label: 
Value" format instead of sentence format (4.x). Either way is fine.

A few format nits if you ever revisit this tab, "Folder Type" should be "Folder 
type" and "Privileges" should be "Privileges..." (since additional action from 
the user is required to complete action).

Comment 5

[David :Bienvenu]

I was leaving bug 112096 open for this remaining issue, which is all that's left
for 112096, AFAIK. Right now, the privileges button runs the account level admin
url instead of the folder admin url, because I haven't written the code to run
the url to fetch the folder admin url, given the folder name.

Comment 6

[David :Bienvenu]

fix upcoming, run xmailboxinfo command to get folder admin url, and then run
that url. Karen, the 6.0 server does not handle this correctly, but I've tried
running 4.x against the 6.x server and had the same problem, so I'm running the
right url.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

Comment 8

[(not reading, please use [e-mail] instead)]

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

sr=sspitzer, just a few nits

>+    if (m_adminUrl.Length())

why not:

if (!m_adminUrl.IsEmpty()) 

>-        if (NS_FAILED(rv = NS_NewURI(getter_AddRefs(uri), manageMailAccountUrl.get())))
>+        if (NS_FAILED(rv = NS_NewURI(getter_AddRefs(uri), m_adminUrl.get())))
>           return rv;

style nit, but since this is your code (imap), do as you please.  but I think
this more readable:

rv = NS_NewURI(getter_AddRefs(uri), m_adminUrl.get());
if (NS_FAILED(rv))
  return rv;

>+    if (NS_FAILED(rv)) return rv;

waterson nit, about debugging:

if (NS_FAILED(rv))
  return rv;

>+            if (m_adminUrl.Length())

why not use !IsEmpty()

Comment 9

[Navin Gupta]

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

r=naving, looks ok

Comment 10

[David :Bienvenu]

fix checked in, with !IsEmpty()

Comment 11

[Aleksey Nogin]

The new nsImapProtocol::SetFolderAdminUrl will return an uninitialized nsresult
when m_imapServerSink is null

Comment 12

[David :Bienvenu]

good catch, but that's basically a catastrophic error, and no reason to reopen
this bug!

Comment 13

[Aleksey Nogin]

I've filed bug 124618 "nsImapProtocol::SetFolderAdminUrl may return an
uninitialized nsresult"

Comment 14

[Karen Huang]

Updating the current status for this bug:
Right now, I am getting the Messenger Express login instead of blank now, but 
after I type in the user id & password for the Messenger Express, I am still 
getting another blank page.....I am still trying to confirm with Messaging 
Server group 6.0 for the different design with Messaging Server 4.15....but at 
least, after users login to Messenger Express, our client shouldn't display 
another blank....At least it should dipslay as following screen shot(compare 
with 4.x client for accessing Messaging Server 6.0), isn't it?

Comment 15

[Karen Huang]

Attachment: screen shot of the page displaying after login to messenger express....

Comment 16

[David :Bienvenu]

Karen, the blank page after the messenger express logon is either a browser bug,
or problem with messenger express's interaction with 6.x - it's not a bug in the
folder privileges button.

Comment 17

[Karen Huang]

I already logged bugzilla bug 125382 and blackflagbug 601767 for tracking either 
our browser problem or Messaging Server 6.0 problems.

Comment 18

[Karen Huang]

Got info from Messaging Server 6.0(from blackflagbug 601767)that this is not the 
problem from Server side.
Looks like this bug currently is blocked by Browser bug 125382, I need to leave 
this bug "as is" until we solve Browser bug 125382, then I can verify this bug 
afterwards. Ccing Scott and adding this bug status on the status whiteboard.

Comment 19

[Karen Huang]

Browser Bug 125382 has been resolved - but this bug has been reopended because 
of Server issues. 
Now, I got the info from the Server group to point to a test server which with 
the latest 6.1 Server good build (20020326). 
With the latest Server build, I am able to implement the folder privileges 
button to share folder and set permissions now. I am marking as verified for 
this bug now.

Comment 20

[Karen Huang]

Attachment: Attach IMAP log of huang3 shared with other "ying" w/read&write on NMS 6.1 w/supports the X-SERVERINFO extension

Comment 21

[Karen Huang]

Copying and paste David comments from bug 38967 here, so we know why this bug 
can only be verified on the imap server which supports the X-SERVERINFO 
extension. (e.g. latest NMS 6.1 (zag.mcom.com)
--------------------------------------------------------------------------------
From [e-mail] 2002-04-02 08:01:
You'll only see the permissions button if your imap server supports the
X-SERVERINFO extension, and supports setting the permissions on your folders
from a web admin page.
--------------------------------------------------------------------------------

Comment 22

[Karen Huang]

Hmm...interesting. 
Looks like something is fixed from the Client side and fix this bug as well 
since I can view Messenger Express info from NMS Server 6.0 (tintin.mcom.com)as 
well now......

Comment 23

[James Pattie]

What imap servers implement the XSERVERINFO extension (other than Netscapes server)?

Would it be possible to add the extension to cyrus?
If so, where can I find some information on how it is to act?  I've googled and
could not find anything talking about using it other than your own IMAP
Interoperability Feature Test Plan documentation and it only names three
arguments to call it by.  I could not find any examples of output or what the
expected values are.

Would it be possible to alternatively use the X-NETSCAPE extension since most
imap servers support it and that would allow me to specify the administration
url that the priviledges button is wanting to use?

Comment 24

[David :Bienvenu]

I don't know if any other IMAP servers support XSERVERINFO. I would think it
could be added to Cyrus, but I know nothing about how hard that would be. 

I didn't know that most servers supported X-NETSCAPE. That's surprising. But if
they do that, it's easy enough to support XSERVERINFO, especially if you're just
going to do the admin url.

The XSERVERINFO command is pretty straightforward. The client asks for url's for
  managing accounts, managing server lists, and server-side filters. The server
returns the urls, if any, NIL otherwise, e.g.:

C - XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL

1208[47db020]: zag.mcom.com:A:CreateNewLineFromSocket: * XSERVERINFO
MANAGEACCOUNTURL {43}

http://zag.mcom.com/cmd/wm.msc?u=huang3&v=o MANAGELISTSURL NIL MANAGEFILTERSURL NIL

Comment 25

[James Pattie]

Is the output supposed to be:
* XSERVERINFO MANAGEACCOUNTURL {X} URL MANAGELISTURL NIL MANAGEFILTERSURL NIL\n

or is the wrapping supposed to be like it is in the log file you snipped the
output from?

What file is doing the client side parsing of this output so I can try to figure
these answers out myself? ;)

Comment 26

[David :Bienvenu]

the wrapping is as I attached it because the url is being returned as a string
literal with a preceding length, e.g., {43} CRLF literal - this doesn't have to
do with the X-SERVERINFO command per se, but IMAP syntax for string literals in
general. The parser would be happy with a quoted literal as well.

The parsing code is in void nsImapServerResponseParser::xserverinfo_data()