Outlook integration2

joejoe2010

Please see aswell https://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?f=4&t=160&p=502&hilit=outlook#p502

Hi,
just about a few thoughts about integrating outlook in openpetra.

What an outlook integration in openpetra should be able to do:
implementing email integration on the client side and provide functionality to keep record of emails that were
sent to a specific partner and to search for all correspondence to this partner within the email client as well as
invoking the email client in order to send a message to this chosen partner.

So I have a question about this:
-Is it right that the sync should happen on the client side with an Outlook installed locally? Would Outlook use Exchange to make sure that on all client computers in one work environment would appear the same emails?

Should the emails then be saved aswell in the openpetra-sever in order to access the emails aswell on client computers where openpetra is running but no outlook?

Greetings
Joachim

pokorra

My thoughts were:
In Outlook/Thunderbird, there is a plugin, that puts a button in the toolbar: Save to OpenPetra.
When you click this button, the plugin connects to a webservice of OpenPetra (eg openpetraorg.sourceforge.net/dbd ... p=mailroom).

There needs to be permissions who can see those emails, but it should be possible for other users with the same permissions, to see the email correspondence with that partner.

The contacts (and emails) have to be searchable within OpenPetra. Christian prepared a prototype for improved contact management several years ago.

In OpenPetra, we should have a button for "Send Email" on the Partner Edit screen, which will open the default email client with the correct Email Address.

The plugin for Outlook/Thunderbird should have a second send button, which will send and save the email to OpenPetra again.

I don't know if there are better solutions to this (perhaps even implementing a simple IMAP client within OpenPetra), but this is my proposal, open for discussion. Best if we had some user feedback on this as well, especially people on the iConnect project, because BBES also has Outlook integration.

matthiasschwarz

I don't think that OpenPetra should store the emails themselves. This would end up in major rights management, storage and synchronization issues.
We also do not want to invent another email system.
OpenPetra should store the contact information: partner's email address, subject and date, if the correspondence has been triggered through OpenPetra.
If the email has not been triggered through OpenPetra, there should be an option to add these few parameters manually in order
to search your emails with more details and that way make it faster.
We cannot allow a superuser to scan all mailboxes for correspondence to chosen partners.
This would not only go against any privacy rules but strictly be legally forbidden.
You also do not want private emails to those persons to be listed and viewed by the public or people with specific rights.
And how could you distinguish public and private if not marking them one by one?
Alternatively you would have to introduce commonly shared email accounts and change the way you are dealing with emails completely.

So storing the basic information (email address, subject and date) - yes
Invoking standard email client to send messages - yes
Search capability through your email client triggered by OpenPetra- yes
Search capability within OpenPetra (header information only) - yes
Storing more detailed information - manually (notes etc.), not through an automated process (sync)

joejoe2010

Hi,

thank you Matthias and Timotheus for your feedback.

I personally would prefer a solution that would be mail-client independent. Because then users who don't have Outlook wouldn't be able to see the emails in openpetra (at least if we don't implement plugins aswell for Thunderbird etc.)
The solution to integrate an IMAP-client seems a good idea for me.
Perhaps we could use one of those:
https://sourceforge.net/projects/sharpwebmail/?source=directory
https://sourceforge.net/projects/roundcubemail/?source=directory
(https://sourceforge.net/projects/davmail/?source=directory)

Then we could disable (for privacy rules) fe. the possibility to see message bodies in openpetra. Or only make mails visible that have been sent within openpetra.

A possible disadvantage for a direct Outlook Add-In would be the need of having Visual Studio Professional for implementing it. I don't know if this would be possible together with the nant tasks.
see the following link: http://en.wikipedia.org/wiki/Visual_Studio_Tools_for_Office#VSTO_compatibility_and_add-in_functionality

What do you think?
Greetings
Joachim

joejoe2010

Using IMAP user restricitons could also be implemented. Or each user could enter his personal IMAP-account data to make sure that others can't see his mails.

Another link for VSTO would be: http://msdn.microsoft.com/en-us/library/bb398242.aspx

pokorra

I was able to build a test Outlook plugin with SharpDevelop a couple of years ago, and I would prefer that over a solution that depends on Visual Studio.
Here is a link to a discussion on StackOverflow:
stackoverflow.com/questions/8415 ... ual-studio
That contains a link to netoffice.codeplex.com/, which could be helpful.

Regarding the other questions, where to store email, and if several users should see the correspondence with a certain partner, we need to ask the users first for their requirements.

matthiasschwarz

As I’ve stated before we won’t store any emails in OpenPetra, just who was contacted when on what subject.
This also means that we won’t need any buttons in Outlook or
other email clients in order to save emails to OpenPetra etc.

What we do want is the ability to send emails to a partner
and to invoke a search functionality through the local email client (no built in OpenPetra imap access)
to retrieve emails that have been sent to this person.
Current Petra uses the Microsoft Exchange MAPI, which then is windows based,
but supports several email clients. I guess this would be the simplest solution for now to start with.
(Netoffice sounds very appealing, too.)

Other than that I agree that the whole area of contact management needs a user review
before we actually start developing it. This includes a range of issues about what to store where and when,
categorizing information, permissions, workflow and follow ups etc.