We think it would be nice if sending an email from Adempiere (from the print preview window) called up the OS's default email program instead of the very basic email dialog that is currently presented. This would allow the user access to their address book and allow their email client to save the sent mail for future reference.
Java 6 has Desktop.mailto(uri) that supports calling the system email client with a URI. However, many email clients do not support attaching files from a URI invocation. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434374
As the point of mailing from the print preview is presumably to attach the document being previewed, this isn't very helpful.
JDIC (https://jdic.dev.java.net) from which the JDK6 desktop api originated, supports invoking the system mail client with attachments. But it currently only supports Windows (outlook, outlook express, thunderbird) and Gnome (thunderbird and evolution). Extending support to other clients would be possible, but should probably be contributed within the JDIC project.
We propose adding a user preference to allow the user to choose which email client to use: Internal (the Adempiere email dialog) or Desktop (via the JDIC api). It would default to internal, and fall back on internal if the desktop mail client is not supported by JDIC, so there should be no adverse effects.
Does this seem like a worthwhile addition to Adempiere?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Paul,
+1 from me, in general, but do have a concern.
The current form allows you to get ADempiere contacts (something I've rarely ever used). But definitely in the scenario of sending the attached doc to the BP that the doc is for, this is a common need. It seems like access to the Adempiere contacts would be lost. And it seems likely that the user might not have all the BP's in their personal address book.
Thanks, Joel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We hope to come up with a means of inserting the "To" address if a contact has been specified in the document being sent. (This is proving to be a bit tricky though - probably why no one else has done it already.)
The available contact list problem cuts both ways. Users often have more (relevant) email addresses in their personal address book than in the Adempiere contacts. Also most email address books are easier to manage and use than the Adempiere contacts search page. One solution to get the best of both worlds might be to automatically publish Adempiere contacts to a global address book of some sort.
And, of course, using the desktop client will be optional and not the default. If people prefer the access to Adempiere contacts over the familiarity of their email client and being able to save a copy to sent mail they aren't required to change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Paul, being parametrizable and backward compatible I think it can be added as you said.
I don't understand the "User Preference" - is that System Configurator?
In Adempiere we're lacking a real "User Preference" table - the current is related to fields preferences mostly.
I would not recommend to use this option (although I'm not against about implementing it).
I think is better to have the corporative e-mails centralized and controlled from adempiere.
Adempiere is saving the history of e-mails sent for everybody to review (opposite to having the sent e-mail on a personal inbox).
And having access to the sent e-mails (all of them from everybody) is really important when solving claims.
Unfortunately Adempiere is saving just the text, not the attachments of the e-mail.
Or maybe an option that saves in AD_UserMail and send it through the personal mail client could make the trick.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the comments. I agree with you both that it is important that there be some centralized control of corporate emails, not only for convenience but also for legislative compliance. However, I don't think that Adempiere comes anywhere near offering the solution for these issues.
The email dialog I am proposing to replace is extremely limited. To my knowledge you can pretty much only access it from the print previewer. You cannot attach additional files to the message. The "history" it records not only does not include the attached document you sent, but is truncated at 2000 characters. (Not that you would want to write more than that in the tiny area provided on the dialog.) It is currently difficult to access the message history (only through the "User" window?) and you cannot "reply to" messages or forward them on. Basically, Adempiere is completely inadequate as a mail client.
Users will not willingly give up their favourite email client for Adempiere's current functionality (have you?), and I don't believe they will even if we spent the effort to create a fully functional email client within Adempiere -- because users want their emails integrated with their calendars and tasks and their instant messages and whatever else. So perhaps it is more pragmatic to accept the fact that users will conduct the majority of their work email communication outside of Adempiere (unless they have to mail a particular Adempiere document). Don't forget we also have to consider the email's sent from home or from a mobile phone or wherever else when the user doesn't have access to Adempiere. And then there's the responses from the client that have to be picked up and somehow stored and tracked (yes, I know there's an "email processor", though I've never been game to try it...). It seems to me that if only a fraction of emails are going through Adempiere, you're not achieving very much.
That doesn't mean you have to give up on controlling emails. But I think the solution probably lies outside of Adempiere. To begin with "Sent mail" doesn't have to be saved as a personal mailbox. IMAP supports shared folders. And at least it is more consistent, rather than having some messages saved in the "sent mail" and some stored in the ADempiere database. A more complete solution would probably start with a complete archive of all mails sent and received through the corporate server. Once you have that, perhaps then you could think about doing some clever things to integrate ADempiere with that archive.
But I think it would be a bad mistake to try to make Adempiere do everything by itself and then force users to limit themselves to what Adempiere is able to provide. That will only serve to push users away. Adempiere is not an email client. Nor is it an email server/archiver. But there are products that do those things (including good quality open source ones). Even if we tried to make Adempiere be those things, it's extremely unlikely we would do as good a job as those projects that are devoted to that one purpose. So the best solution for me is for Adempiere to be able to interact with the best existing solutions, rather than trying to reinvent them. Then Adempiere can focus on the doing the things it is good at. That's why we have chosen to try integrating Adempiere with the user's desktop mail client, rather than trying to improve the built in dialog to make up for it's shortcomings.
Apologies for the long post,
Regards,
Paul
By the way, the "preferences" I was referring to are those accessed through the Tools->Preference menu and stored on the client in the properties file, so it is a per user/desktop option. Perhaps you may wish to add some security to control whether people have access to this option or not. Also, it would be possible to save information about the sent mail (including attachment) before calling the desktop mail client, however there would be no way of knowing if the mail was altered or indeed sent by the external application, so it would be of limited benefit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Paul - agree with you - we must not reinvent the wheel here (ala JJ)
Recently in another thread I said something similar about reporting engine - I consider the internal reporting engine can be enhanced - but we're far from Jasper, and the best approach was exactly the jasper integration.
Same here - mail window, or mail management can be improved - but it would be a mistake (as you point) to try to make a complete e-mail client. The solution (as you point) must be to find some sort of integration with e-mail clients or servers.
IMAP shared folders? integration through a corporative e-mail google account? zimbra?
I've seen several posts pointing this way. I think a good approach could be a "collector"/"classifier" of e-mails.
Users can use their personal e-mail - it must be configured to save things in server - and a collector/classifier process could read the server and import basic info to adempiere and link to the server (or something like that).
That's also why I said I'm not against your suggestion (as a start) - and probably we're going to need more work on this for a complete integration.
------------------
About preferences I think this window is unsafe and we must consider some new mechanism to store user preferences (I think I've proposed something in another old thread).
Preferences window is unsafe (for example I would like to hide "save password" from users, but I can't without customization).
Maybe a "User Configurator" window similar to "System Configurator" could make the trick.
But as this window is for final user (not administrator) we would need to restrict and control the domain of possible values for the parameters.
It must be easy to define the level and change permissions on each parameter (as we did in System Configurator -> System/Client/Org - in this case we would add a new User level).
And even further we could implement some sort of role/parameter permissions table.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would be cautious about recommending this change. The reason is that the contacts should be in adempiere otherwise you loose control of your enterprise contacts. Also, you loose the logging of the business partner contacts in email and the singular view of the relationship. In addition, we try to encourage customers to use the system to the greatest extent so that adempiere becomes their 'work bench' or desktop. Adempiere does provide email functionality (and I agree it could be improved) so it seems logical to me to focus the user to interact within adempiere rather than giving them additional (and uncontrolled) applications.
Having said that, there are probably some users who do not require access to adempiere and require email, or perhaps have limited access to adempiere and perhaps it isn't appropriate for them to manage their contacts within the system. For example, sales people who are prospecting might have a large database of 'possibles' that perhaps the user decides they don't want in adempiere. In this case, we tend to use a different tool (i.e. like sugarcrm)
On a side note, I understand some people have integrated ldap for adempiere and perhaps that is another way of getting the contacts in to adempiere - many email clients allow contacts to be stored in the same database. I've not tried this myself.
Perhaps you've got another scenario in mind ?
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We think it would be nice if sending an email from Adempiere (from the print preview window) called up the OS's default email program instead of the very basic email dialog that is currently presented. This would allow the user access to their address book and allow their email client to save the sent mail for future reference.
Java 6 has Desktop.mailto(uri) that supports calling the system email client with a URI. However, many email clients do not support attaching files from a URI invocation. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434374
As the point of mailing from the print preview is presumably to attach the document being previewed, this isn't very helpful.
JDIC (https://jdic.dev.java.net) from which the JDK6 desktop api originated, supports invoking the system mail client with attachments. But it currently only supports Windows (outlook, outlook express, thunderbird) and Gnome (thunderbird and evolution). Extending support to other clients would be possible, but should probably be contributed within the JDIC project.
We propose adding a user preference to allow the user to choose which email client to use: Internal (the Adempiere email dialog) or Desktop (via the JDIC api). It would default to internal, and fall back on internal if the desktop mail client is not supported by JDIC, so there should be no adverse effects.
Does this seem like a worthwhile addition to Adempiere?
Hi Paul,
+1 from me, in general, but do have a concern.
The current form allows you to get ADempiere contacts (something I've rarely ever used). But definitely in the scenario of sending the attached doc to the BP that the doc is for, this is a common need. It seems like access to the Adempiere contacts would be lost. And it seems likely that the user might not have all the BP's in their personal address book.
Thanks, Joel
We hope to come up with a means of inserting the "To" address if a contact has been specified in the document being sent. (This is proving to be a bit tricky though - probably why no one else has done it already.)
The available contact list problem cuts both ways. Users often have more (relevant) email addresses in their personal address book than in the Adempiere contacts. Also most email address books are easier to manage and use than the Adempiere contacts search page. One solution to get the best of both worlds might be to automatically publish Adempiere contacts to a global address book of some sort.
And, of course, using the desktop client will be optional and not the default. If people prefer the access to Adempiere contacts over the familiarity of their email client and being able to save a copy to sent mail they aren't required to change.
Hi Paul, being parametrizable and backward compatible I think it can be added as you said.
I don't understand the "User Preference" - is that System Configurator?
In Adempiere we're lacking a real "User Preference" table - the current is related to fields preferences mostly.
I would not recommend to use this option (although I'm not against about implementing it).
I think is better to have the corporative e-mails centralized and controlled from adempiere.
Adempiere is saving the history of e-mails sent for everybody to review (opposite to having the sent e-mail on a personal inbox).
And having access to the sent e-mails (all of them from everybody) is really important when solving claims.
Unfortunately Adempiere is saving just the text, not the attachments of the e-mail.
Or maybe an option that saves in AD_UserMail and send it through the personal mail client could make the trick.
Regards,
Carlos Ruiz
Hi Carlos and Mike,
Thanks for the comments. I agree with you both that it is important that there be some centralized control of corporate emails, not only for convenience but also for legislative compliance. However, I don't think that Adempiere comes anywhere near offering the solution for these issues.
The email dialog I am proposing to replace is extremely limited. To my knowledge you can pretty much only access it from the print previewer. You cannot attach additional files to the message. The "history" it records not only does not include the attached document you sent, but is truncated at 2000 characters. (Not that you would want to write more than that in the tiny area provided on the dialog.) It is currently difficult to access the message history (only through the "User" window?) and you cannot "reply to" messages or forward them on. Basically, Adempiere is completely inadequate as a mail client.
Users will not willingly give up their favourite email client for Adempiere's current functionality (have you?), and I don't believe they will even if we spent the effort to create a fully functional email client within Adempiere -- because users want their emails integrated with their calendars and tasks and their instant messages and whatever else. So perhaps it is more pragmatic to accept the fact that users will conduct the majority of their work email communication outside of Adempiere (unless they have to mail a particular Adempiere document). Don't forget we also have to consider the email's sent from home or from a mobile phone or wherever else when the user doesn't have access to Adempiere. And then there's the responses from the client that have to be picked up and somehow stored and tracked (yes, I know there's an "email processor", though I've never been game to try it...). It seems to me that if only a fraction of emails are going through Adempiere, you're not achieving very much.
That doesn't mean you have to give up on controlling emails. But I think the solution probably lies outside of Adempiere. To begin with "Sent mail" doesn't have to be saved as a personal mailbox. IMAP supports shared folders. And at least it is more consistent, rather than having some messages saved in the "sent mail" and some stored in the ADempiere database. A more complete solution would probably start with a complete archive of all mails sent and received through the corporate server. Once you have that, perhaps then you could think about doing some clever things to integrate ADempiere with that archive.
But I think it would be a bad mistake to try to make Adempiere do everything by itself and then force users to limit themselves to what Adempiere is able to provide. That will only serve to push users away. Adempiere is not an email client. Nor is it an email server/archiver. But there are products that do those things (including good quality open source ones). Even if we tried to make Adempiere be those things, it's extremely unlikely we would do as good a job as those projects that are devoted to that one purpose. So the best solution for me is for Adempiere to be able to interact with the best existing solutions, rather than trying to reinvent them. Then Adempiere can focus on the doing the things it is good at. That's why we have chosen to try integrating Adempiere with the user's desktop mail client, rather than trying to improve the built in dialog to make up for it's shortcomings.
Apologies for the long post,
Regards,
Paul
By the way, the "preferences" I was referring to are those accessed through the Tools->Preference menu and stored on the client in the properties file, so it is a per user/desktop option. Perhaps you may wish to add some security to control whether people have access to this option or not. Also, it would be possible to save information about the sent mail (including attachment) before calling the desktop mail client, however there would be no way of knowing if the mail was altered or indeed sent by the external application, so it would be of limited benefit.
Hi Paul - agree with you - we must not reinvent the wheel here (ala JJ)
Recently in another thread I said something similar about reporting engine - I consider the internal reporting engine can be enhanced - but we're far from Jasper, and the best approach was exactly the jasper integration.
Same here - mail window, or mail management can be improved - but it would be a mistake (as you point) to try to make a complete e-mail client. The solution (as you point) must be to find some sort of integration with e-mail clients or servers.
IMAP shared folders? integration through a corporative e-mail google account? zimbra?
I've seen several posts pointing this way. I think a good approach could be a "collector"/"classifier" of e-mails.
Users can use their personal e-mail - it must be configured to save things in server - and a collector/classifier process could read the server and import basic info to adempiere and link to the server (or something like that).
That's also why I said I'm not against your suggestion (as a start) - and probably we're going to need more work on this for a complete integration.
------------------
About preferences I think this window is unsafe and we must consider some new mechanism to store user preferences (I think I've proposed something in another old thread).
Preferences window is unsafe (for example I would like to hide "save password" from users, but I can't without customization).
Maybe a "User Configurator" window similar to "System Configurator" could make the trick.
But as this window is for final user (not administrator) we would need to restrict and control the domain of possible values for the parameters.
It must be easy to define the level and change permissions on each parameter (as we did in System Configurator -> System/Client/Org - in this case we would add a new User level).
And even further we could implement some sort of role/parameter permissions table.
Regards,
Carlos Ruiz
Hi Paul,
I would be cautious about recommending this change. The reason is that the contacts should be in adempiere otherwise you loose control of your enterprise contacts. Also, you loose the logging of the business partner contacts in email and the singular view of the relationship. In addition, we try to encourage customers to use the system to the greatest extent so that adempiere becomes their 'work bench' or desktop. Adempiere does provide email functionality (and I agree it could be improved) so it seems logical to me to focus the user to interact within adempiere rather than giving them additional (and uncontrolled) applications.
Having said that, there are probably some users who do not require access to adempiere and require email, or perhaps have limited access to adempiere and perhaps it isn't appropriate for them to manage their contacts within the system. For example, sales people who are prospecting might have a large database of 'possibles' that perhaps the user decides they don't want in adempiere. In this case, we tend to use a different tool (i.e. like sugarcrm)
On a side note, I understand some people have integrated ldap for adempiere and perhaps that is another way of getting the contacts in to adempiere - many email clients allow contacts to be stored in the same database. I've not tried this myself.
Perhaps you've got another scenario in mind ?
Mike