Hi Milan, Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha: > On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: > > * IMAP ACL management. A new tab (or something alike) when > > right-clicking an IMAP folder in the Evo folder tree to view and > > edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP > > ACL functionality will be implemented on a new branch based on A-B > > (see "Phase I, (1)"), much the same way ANNOTATEMORE has been > > implemented, to the extend needed for Kolab. This will lead to an > > API extension (like there already is in evolution-kolab-IMAPX). > > There will be the need to extend Evolution as well, as to make it > > use this API extension. It is currently not yet planned exactly how > > this can be done without littering Evolution with "the tacking on of > > arbitrary features" (MBarnes, [3]) > > (Kolab specific: no) > > Hi, > see how evolution-exchange provides the same functionality of Folder > Permissions, it just adds a popup menu item and servers all what is > needed without any special modification on evolution side. The same > should apply for the folder type annotation editing - no change on > evolution should be needed. I'll check that. The less change needed on Evo side the better. I'm not sure yet exactly how we will be able to solve it. I do not have knowledge about how folders are handled in Exchange, but for Kolab, it is IMAP - so we need the capability for IMAP ACL, which, unless I'm mistaken, IMAPX does not yet provide. This part will be done (for now) in our IMAPX derivative, and Evo will need to make use of this functionality one way or another. ACL management is not limited to the evolution-kolab backends and is needed for the Kolab email folders (which are plain IMAP folders) as well. Maybe we can do this in an EExtension, I'll check with evolution-exchange. If the UI extension evolution-exchange provides is fine for the Evo community (which I think it is), then we could try to mimick the layout in order to try for a consistent user experience. To that respect, maybe it will be possible to iron out some common approach for the groupware plugins that way, which I think is what Matt has in mind. > With respect of creating a new folder on the kolab server other than > mail: when you do File->New->Calendar and select the Kolab group, is it > able to create a new folder and annotate it accordingly to the source > group? Evolution-mapi provides a short folder list with folders of the > certain type from which user can choose and under this is created the > new calendar (or address book). Again, no change on evo side is needed > for this. As far as creating new PIM folders goes, this is correct. This can be done entirely in the backends, provided we can re-use existing account information (which in current Evo/E-D-S should be possible). Things are different when you need to change or set the type of an existing folder manually. This is for error recovery mainly, but has been described by our sponsor as a real life scenario which from time to time happens to occur (due to server failure or client error). To do this, it will be made possible to display the PIM folders in the email folder tree (though these folder's contents will not be accessible), so you can right-click the folder and edit the annotation it carries by selecting a type from a drop down list. This is the typical way Kolab clients will provide this functionality for the user. There are a number of issues related to this, e.g. the kolab backends need to be notified of the change do they can sort of "drop" a folder they are no longer supposed to care for ... whether or not we can sanely implement this remains to be seen. The goal behind this is to enable Evolution to act as a complete Kolab client, removing the need to resort to different clients to get all tasks done. Kind regards and thanks for the hints, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.