User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 When using Cyrus 2.1.13 as the IMAP server, Mozilla appears to not behave as defined in the IMAP ACL feature test spec (http://www.mozilla.org/quality/mailnews/tests/machv-mn-imap-shared-folders.html). As like the picture shows (http://www.mozilla.org/mailnews/specs/folder/#Sharing) I see the folder type, shared, and permissions but no set privileges/permissions button. Exactly what I do see in the shared tab is: "... Folder Type: Personal Folder This is a personal mail folder. It is not shared. You have the following permissions: Full Control ..." The feature test spec states that either the above is shown with a button for setting shared privileges, or the user is simply told that the server does not support shared folders - it appears that I've hit a halfway point... Reproducible: Always Steps to Reproduce: 1. Create IMAP folder 2. Select the shared tab from the folder properties Actual Results: Set Privileges button is not there Expected Results: Shown either the set privileges button, or just stated that the server does not support shared folders.
It's simply not implemented, and I don't think it will be. The set privileges button is only for servers that support an admin url, so that clicking the set privileges button actually brings up a browser window and some server-based admin page. We never intended to implement a client-side UI for setting admin rights; I'm sorry if the spec did not make that clear.
Severity: major → enhancement
Summary: IMAP shared folder privileges button does not appear → [RFE] Implement set privileges button for servers that don't support an admin url
Wow, thanks for the quick response. Is there any IMAP4 server which does give out this "admin url", and/or is there any way to configure Cyrus to do this (I suppose the latter is a question for the Cyrus folks, or Google...)?
The i-planet/Netscape mail server does. I don't know if any other server does, or if cyrus has a web-based admin ui. If it does, but doesn't support the extension to get the admin url, you can set a pref for the admin url in prefs.js, in theory. As I understand it, we tried a number of years ago to get other servers to support the admin url extension, but I don't think there were any takers (I don't know how hard we tried, though, since it was a server-side effort and I work on the client)
Status: UNCONFIRMED → NEW
Ever confirmed: true
What is the "C01 CAPABILITY" that Mozilla is looking for?
XSERVERINFO the XSERVERINFO command looks like this XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL" though we only use the MANAGEACCOUNTURL.
Thanks for the additional info. In regards to the IMAP ACL extension, if anyone is able to implement this, there is a 7 page RFC that's used by the Cyrus folks (and I'd assume others as well). It's RFC 2086 (www.ietf.org/rfc/rfc2086.txt). The implementation/RFC looks pretty straightforward, but of-course, I'm not a programmer :-) If someone is intrested in doing this - I'd be happy to setup an account (or two+) on my systems. The Cyrus folks also have a test server (http://asg.web.cmu.edu/cyrus/cyrustest.html), though I dont know to what extent they allow ACL tests/changes.
This seems a duplicate of bug 135977
*** Bug 135977 has been marked as a duplicate of this bug. ***
yes, thx, duping that against this one, since I already own this one.
Ok, I'll copy&paste here my RFE from bug 135977: Bug 38967 deals with the implementation of the ACL functionality for an IMAP account. The implementation is only partial, though, because it only deals with displaying the rights on a folder (and only for the logged in user, not showing rights granted to other users) and not with setting them (SETACL and DELETEACL commands in rfc2086). Another problem with the implementation of bug 38967 is that the ACL is fetched only once, and if it is modified externally to mozilla (as there's no other option currently) the shown rights won't reflect reality. A possible implementation would be, in the "sharing" tab: a) To show the rights for all users that can access the folder b) To fetch the rights from the server any time the "sharing" tab is shown c) If the user has the "a" (administer) right, offer her the option to modify the rights for the folder. The implementation of c) could be a dialog with 1) a text field to introduce the name of another user (since mozilla doesn't know anything about other users) with a checkbox for each possible right 2) a line for each user that currently has rights on the folder with a checkbox for each possible right 3) a button to confirm the action
*** Bug 230817 has been marked as a duplicate of this bug. ***
Comment #3 mentions the ability to define the IMAP AdminURL via a prefs.js entry; about:config doesnt show anything which seems to pertain to setting such a URL. What's the string I need to set?
OS: Linux → All
(In reply to comment #5) > XSERVERINFO > > the XSERVERINFO command looks like this > > XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL" > > though we only use the MANAGEACCOUNTURL. > > It seems mozilla is doing it differently than communicator. Cyrus has a workaround (because the correct solution would be managing ACLs from the client, not from a web based hack) using --enable-netscapehack and the netscapeurl option in /etc/imapd.conf and it works with communicator but not with mozilla. The capability for netscape was X-NETSCAPE and the command NETSCAPE. While mozilla implements the "right thing(tm)" a similar workaround could be implemented for mozilla if the command and the expected response is documented somewhere (I doubt the patch would be accepted upstream though).
changing summary to include setting IMAP ACL
Summary: [RFE] Implement set privileges button for servers that don't support an admin url → [RFE] Implement set privileges button to set IMAP ACL for servers that don't support an admin url
*** Bug 261382 has been marked as a duplicate of this bug. ***
*** Bug 261396 has been marked as a duplicate of this bug. ***
*** Bug 261398 has been marked as a duplicate of this bug. ***
*** Bug 261400 has been marked as a duplicate of this bug. ***
Looks like a lot of people want proper support for IMAP ACL control built into the mozila folder property's tool. This seems like a much more suitable approach than having to create and support a seperate admin website to manage the access rights to a folder on your imap server.
Mozilla/Thunderbird should implement the new IMAP ACL scheme http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt. The new ACL scheme updates list of rights: - the *d*: delete a message, perform expunge and delete mailbox is splited into 3 new rughts: - *x*: delete mailbox (DELETE mailbox, old mailbox name in RENAME); - *t*: delete messages (set or clear \DELETED flag via STORE, set \DELETED flag during APPEND/COPY); - *e*: perform EXPUNGE and expunge as a part of CLOSE. Also, a new right is created: - *n*: write shared annotations [ANNOTATE]
I'd love to see setting ACLs implemented client-side. An example of an IMAP client that has this functionality is Mulberry. (My employer happens to standardize on Mulberry, so if one wants to change ACLs, the standard response is "use Mulberry." So I have to keep it around despite having used Mozilla for mail for years.)
(In reply to comment #21) > I'd love to see setting ACLs implemented client-side. An example of an IMAP > client that has this functionality is Mulberry. (My employer happens to > standardize on Mulberry, so if one wants to change ACLs, the standard response > is "use Mulberry." So I have to keep it around despite having used Mozilla for > mail for years.) All advanced IMAP users are waiting for ACL implementation in Thunderbird - we need to share folders. ;-) I wish Thunderbird could become as good as Mulberry. Please, see this link for inspiration http://www.cyrusoft.com/sites/siteservers.html#acls. Jon Udell wrote in _Practical Internet Groupware_ "Finally, some IMAP servers support public folders, which work very much like newsgroups. When IMAP's full capability is deployed, *an NNTP newsgroup is no more effective as a shared* *central repository than an IMAP public folder*. http://www.oreilly.com/catalog/pracintgr/chapter/ch03_02.html "Unlike email, conferencing creates and uses a central data store. What about *email archives and IMAP public folders*? It's true that in these cases, email can read and write a central data store. But then, I argue, it's acting more like a *conferencing system* than like email". http://www.oreilly.com/catalog/pracintgr/chapter/ch01_05.html I hope I'm convincing.
> All advanced IMAP users are waiting for ACL implementation > in Thunderbird - we need to share folders. ;-) I'm working for a government organisation here in Australia and the main reason we are not deploying Thunderbird to nearly 10,000 people is because it doesn't support Shared Folders properly. Why is it that Mozilla Mail works, yet Thunderbird does not?
Thunderbird supports shared folders to the same extent as Mozilla Mail, AFAIK. Neither allow the setting of ACL, but both respect ACL settings. What do you mean when you say Thunderbird doesn't support shared folders?
I have Mozilla 1.7.5 and Thunderbird 1.0 installed on my machine. Both are configured exactly the same way to connect to a Netscape/iPlanet/SunONE/Sun Java Station Messaging Server. When I click 'Permissions' to set ACL details in Mozilla, it works - it takes me to the admin URL. However, when in Thunderbird, if I click 'Permissions', it just sits there doing nothing. Eventually it'll time out. Unless I am doing something wrong which is so obvious that I'm overlooking it, I really don't think Thunderbird works as expected. The previous versions I've tried, 0.8 and 0.9 also had the same problem.
ah, thx for the info - I didn't realize you were talking about the admin url. We will need to fix that...
nsMsgContentPolicy::ShouldLoad() is rejecting the load of the http url. We need to figure out some way to allow this url. We're calling rv = docShell->LoadURI(uri, nsnull, nsIWebNavigation::LOAD_FLAGS_IS_LINK, PR_FALSE); to run the url from nsImapMailFolder.
This bug is about supporting RFC2086 (specifically 4.1, SETACL), not supporting a non standard propietary feature of a single imap server.
This bug is about facilitating the editing of already supported RFC2086 from within the mail client. RFC2086 doesn't state how to administer ACLs; it merely states what to do when certain rights exist and how to read/write the rights (from a client and server application perspective). However, I agree, this bug report is not about correcting a (now) known bug in the existing administration of ACLs, albeit non standard. I shall raise another bug to cover this. My apologies for straying off topic.
*** Bug 254219 has been marked as a duplicate of this bug. ***
With the webmail interface HORDE/IMP can also set ACL directly in the cyrus server. No need for a special admin url.
So do you recommend we bundle HORDE with Thunderbird? Be serious. The point is that you should be able to manage your folders in Thunderbird.
Comment #31: SquirrelMail can also manage Cyrus folders, though both Horde and SquirrelMail are WebMail-only options. Comment #32 is correct, we need this functionlity in Thunderbird itself.
Comment #32: Of course, why not also bundle cyrus so we have a common imap server and don't need to worry about others.... No, my point is that at least HORDE/IMP, Mullbery and SquirrelMail have implemented this functionality in the mail useragent. So why can't Thunderbird do it ? Beside this, our major competitor has a product where you can also share folders and give access for other users. (Ok, only with it's proprietary backend server, but sometimes this is the reason why such a server is demanded by the users)
I want to use TBird as a corporate frontend with lightning and egroupware. for that thuis functionality is essential folks ...
Maik, does the parser basically just check for OK/No/BAD for the passthrough command? I assume apassthrough command can be anything...
Just added a patch introducing a new scriptable method to interface nsIMsgImapFolder, named issuePassthrough and a new attribute fullACLList. So it doesn't implement a straight acl support but a general method for issueing any command. This was mainly done by copy/paste from the existing method issueCommandOnMsgs. A working extension can be downloaded at www.flipperninhamburg.de. It is most certainly bad and maybe even dangerous, might break other things, i can't tell. I see this merely as a start to get things rolling, and as a base for further discussions, how things should be implemented. I think it would be best to just implement the low level acl functions and make them scriptable and leave the rest to an extension, as it would be easier to match different server implementations or environments e.g. ldap integration for username checking. On the other hand, the passthrough method is quite handy, since any special server extensions can be made use of.
(In reply to comment #37) > Maik, does the parser basically just check for OK/No/BAD for the passthrough > command? I assume apassthrough command can be anything... > The existing serverresponse parser is nearly untouched, since it already contained the necessary parsers for the ACL response and customCommandResponse for LISTRIGHTS. Just the acl_data() got a line added to fill in the new nsIMsgImapFolder interface attribute 'fullACLList'.
(In reply to comment #38) > A working extension can be downloaded at www.flipperninhamburg.de. This is a really cool enhancement. Thanks. Is it based on RFC 2086 or on RFC 4314 ? BTW, I tried to download the extension but can't find it on your blog. Is it available in XPI ?
(In reply to comment #40) > Is it based on RFC 2086 or on RFC 4314 ? > The extension is based on RFC 2086, but can be easily extended, it's very simple. > BTW, I tried to download the extension but can't find it on your blog. Is it > available in XPI ? > in the menu on the right side, the link called 'Patch + extension-v0.4". It's a zip containing the patch and a xpi.
(In reply to comment #41) > in the menu on the right side, the link called 'Patch + extension-v0.4". It's a > zip containing the patch and a xpi. Thanks. I've just installed the XPI on Thunderbird 22.214.171.124 (20070716) X11/UbuntuFeisty but can't seem to modify the ACLs (of a Cyrus server). When right-clicking on a mailbox, it only displays : "Folder Type : Personal folder This is a personal mail folder - It has been shared You have the following permissions : Full control" Here are the server capabilities : 01 capability * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=NTLM AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=ANONYMOUS SASL-IR *ACL* *RIGHTS=kxte* QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE URLAUTH BTW, not related to the patch, wondering why it displays "It has been shared" ; I don't remember having shared it.
(In reply to comment #42) Ok, forgot to mention one thing: It provides a new button, so right-click on your toolbar, select customize and drag the new 'Sharing' button (red 'S') into your toolbar. Select a folder and hit the button. > BTW, not related to the patch, wondering why it displays "It has been shared" ; > I don't remember having shared it. This i always wondered about too, and understood only when i looked at the sources: if the ACL contains two or more users, or 'anyone', it is considered shared. On cyrus, every folder is shared, because the acl contain at least the user and 'cyrus'. Because of this, I plead for completely removing the GUI-Part from TB and leave that to an extension customized for the specific server/environment.
(In reply to comment #43) > Ok, forgot to mention one thing: It provides a new button, so right-click on > your toolbar, select customize and drag the new 'Sharing' button (red 'S') into > your toolbar. Select a folder and hit the button. I get it. What are the assigned rights when clicking on a mailbox ? It'd be great to have a granular assignment so that it'd be possible to assign different set of rights (lookup, write, seen, etc) to different users, and eventually bundle of ACL rights (like Mulberry "ACL style"). > > BTW, not related to the patch, wondering why it displays "It has been shared" ; > > I don't remember having shared it. > > This i always wondered about too, and understood only when i looked at the > sources: if the ACL contains two or more users, or 'anyone', it is considered > shared. On cyrus, every folder is shared, because the acl contain at least the > user and 'cyrus'. > Because of this, I plead for completely removing the GUI-Part from TB and leave > that to an extension customized for the specific server/environment. Well, now that Thunderbird is the second IMAP client supporting ACL, it might be better to have a complete native ACL implementation. When right-clicking on a mailbox, users would assign rights like with Mulberry (cf. the second screenshot of <http://help.unc.edu/?id=72#d23349e59>) or the IMAP ACL Manager (<http://www.tcnj.edu/~ssivy/imapacl/index.html>). Regarding the cyrus user, it'd be present but its rights wouldn't modifiable (since they cannot be changed).
ok, I may be daft, but how do I install the patch? thanks Bernhard
I'd like nominate it as wanted‑thunderbird3, I know only one client on Windows platform - Mulberry who works with ACL in this way.
Would be very nice, but unless someone provides a patch, I don't see this making thunderbird3. wanted‑thunderbird3-
Flags: wanted-thunderbird3? → wanted-thunderbird3-
Hardware: x86 → All
errrm, what about the patch that is attached?
Comment on attachment 276287 [details] [diff] [review] Patch introducing a passthrough method The patch comment says "It is most certainly bad and maybe even dangerous, might break other things, i can't tell." That, and afaikt, it's just hacky first a step on the way.
Attachment #276287 - Attachment is obsolete: true
I implemented Setacl functionality as an extension, if anyone wants to use it: https://addons.mozilla.org/en-US/thunderbird/addon/176736
You need to log in before you can comment on or make changes to this bug.