currently the 'createCommunicationEvent' expects for the content a string, in the database it is a 'CLOB'. The same for updateCommunicationevent... In order to store an simple email that is no problem, however i would like to store a multipart/mixed email in here too and using the same service. has anybody a problem to change this service that the 'content' input field is an 'object' so we can store anything in here? or create some new services perhaps using the sameservice code? please your advice here.... -- Regards, Hans Bakker ANT Websystems Co.,Ltd (http://www.antwebsystems.com) If you want to verify that this message really originates from from the above person, download the public key from: http://www.antwebsystems.com/hbakkerAntwebsystems.asc _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev attachment0 (196 bytes) Download Attachment |
Not sure why it needs to be changed.
email is sent as text, by default, even multi part email. binary is converted to text was well. it is up to the mail client to convert this to a readable form. so after it is stored the application that is reading it should to the conversion. the communication module should read just the header and not an attachment for display. Then so the conversion when the email is opened. but as far as getting it passed and stored, CLOB seems to fit the bill. Hans Bakker sent the following on 3/23/06 1:58 AM: > currently the 'createCommunicationEvent' expects for the content a string, in > the database it is a 'CLOB'. The same for updateCommunicationevent... > > In order to store an simple email that is no problem, however i would like to > store a multipart/mixed email in here too and using the same service. > > has anybody a problem to change this service that the 'content' input field is > an 'object' so we can store anything in here? > > or create some new services perhaps using the sameservice code? > > please your advice here.... > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
On Thursday 23 March 2006 17:45, BJ Freeman wrote:
> Not sure why it needs to be changed. > email is sent as text, by default, even multi part email. > binary is converted to text was well. good point, i forgot about that. thanks for your reply...no change required.... -- Regards, Hans Bakker ANT Websystems Co.,Ltd (http://www.antwebsystems.com) If you want to verify that this message really originates from from the above person, download the public key from: http://www.antwebsystems.com/hbakkerAntwebsystems.asc _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev attachment0 (196 bytes) Download Attachment |
Hans,
We need to expand the entities to have separately stored attachments and by extension the services which support them. David and I discussed this on the list before: http://jira.undersunconsulting.com/browse/OFBIZ-665 Si Hans Bakker wrote: On Thursday 23 March 2006 17:45, BJ Freeman wrote:Not sure why it needs to be changed. email is sent as text, by default, even multi part email. binary is converted to text was well.good point, i forgot about that. thanks for your reply...no change required.... _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
I am working on a contract that needs these issues resolved. They
definitely need what Hans was asking for - email attachments saved as content entities. If I understand what BJ was saying, I don't think relying on an email client to correctly regurgitate an email will do. I will be studying the JIRA issue below more fully and we should be able to add this feature in the next week. -Al Si Chen wrote: > Hans, > > We need to expand the entities to have separately stored attachments > and by extension the services which support them. David and I > discussed this on the list before: > http://jira.undersunconsulting.com/browse/OFBIZ-665 > > Si > > Hans Bakker wrote: > >>On Thursday 23 March 2006 17:45, BJ Freeman wrote: >> >> >>>Not sure why it needs to be changed. >>>email is sent as text, by default, even multi part email. >>>binary is converted to text was well. >>> >>> >> >>good point, i forgot about that. >>thanks for your reply...no change required.... >> >> >>------------------------------------------------------------------------ >> >> >>_______________________________________________ >>Dev mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/dev >> >------------------------------------------------------------------------ > > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
based on the comments, it would probably be best to have services to
store and retrieve attachments, as part of the content, since there are already some of this in place. Then the functions in the email (communication) module can take advantage of these. Since mime has been introduces, it would seem to store the attachment as text, like email then have the enttites for that mime do the conversion. Al Byers sent the following on 3/23/06 7:23 AM: > I am working on a contract that needs these issues resolved. They > definitely need what Hans was asking for - email attachments saved as > content entities. If I understand what BJ was saying, I don't think > relying on an email client to correctly regurgitate an email will do. > > I will be studying the JIRA issue below more fully and we should be able > to add this feature in the next week. > > -Al > > Si Chen wrote: > > >>Hans, >> >>We need to expand the entities to have separately stored attachments >>and by extension the services which support them. David and I >>discussed this on the list before: >>http://jira.undersunconsulting.com/browse/OFBIZ-665 >> >>Si >> >>Hans Bakker wrote: >> >> >>>On Thursday 23 March 2006 17:45, BJ Freeman wrote: >>> >>> >>> >>>>Not sure why it needs to be changed. >>>>email is sent as text, by default, even multi part email. >>>>binary is converted to text was well. >>>> >>>> >>> >>>good point, i forgot about that. >>>thanks for your reply...no change required.... >>> >>> >>>------------------------------------------------------------------------ >>> >>> >>>_______________________________________________ >>>Dev mailing list >>>[hidden email] >>>http://lists.ofbiz.org/mailman/listinfo/dev >>> >> >>------------------------------------------------------------------------ >> >> >>_______________________________________________ >>Dev mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/dev >> > > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
In reply to this post by byersa
Music to my ears :)
Si Al Byers wrote: I am working on a contract that needs these issues resolved. They definitely need what Hans was asking for - email attachments saved as content entities. If I understand what BJ was saying, I don't think relying on an email client to correctly regurgitate an email will do. I will be studying the JIRA issue below more fully and we should be able to add this feature in the next week. -Al Si Chen wrote:Hans, We need to expand the entities to have separately stored attachments and by extension the services which support them. David and I discussed this on the list before: http://jira.undersunconsulting.com/browse/OFBIZ-665 Si Hans Bakker wrote:On Thursday 23 March 2006 17:45, BJ Freeman wrote:Not sure why it needs to be changed. email is sent as text, by default, even multi part email. binary is converted to text was well.good point, i forgot about that. thanks for your reply...no change required.... ------------------------------------------------------------------------ _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev------------------------------------------------------------------------ _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
> I am working on a contract that needs these issues resolved. They
> definitely need what Hans was asking for - email attachments saved as > content entities. If I understand what BJ was saying, I don't think > relying on an email client to correctly regurgitate an email will do. Make sure you test it not only with correct emails, but the nastiest, most malformed junky spam emails that you can find. There is some stuff out there that throws weak parsers for a loop, so to speak. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
David Welton wrote:
>> I am working on a contract that needs these issues resolved. They >>definitely need what Hans was asking for - email attachments saved as >>content entities. If I understand what BJ was saying, I don't think >>relying on an email client to correctly regurgitate an email will do. >> >> > >Make sure you test it not only with correct emails, but the nastiest, >most malformed junky spam emails that you can find. There is some >stuff out there that throws weak parsers for a loop, so to speak. > >-- >David N. Welton > - http://www.dedasys.com/davidw/ > >Linux, Open Source Consulting > - http://www.dedasys.com/ > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > > > OFBiz MCA (mail condition action) framework uses. I believe that the current mail.jar is at version 1.2. The lastest stable version is 1.3.3. It has providers for secure authentications, which 1.2 does not. So I would guess we will need to update the version. I am working with 1.3.3 now. From what I have seen, I can tell that you are right, David - parsing emails will not be simplistic. Do you have an "approach"? Does anyone? This is an area where reading someone else's code, even if it does not use JavaMail, would save a lot of time in figuring out what to do. Does anyone who is interested in this subject have an MSExchange server on which they could give me a test account and be willing to tell me what the logs say if I cannot connect? -Al _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
In reply to this post by BJ Freeman
As of now, I plan on writing services that do two things in the course
of processing an email (in addition to creating the CommunicationEvent): 1. Reverse find the partyIds from the fromAddress and recipients. Not sure about creating skeleton Party/Person/ContactMech entries if they do not exist. 2. Add content attachments to CommEvent. Will create a CommunicationEventContent entity as discussed in the JIRA ( http://jira.undersunconsulting.com/browse/OFBIZ-665) While I am at it, I did this little table to show what commonly used entities have "glue" to commevents and content and notes: CommEvent Content Note WorkEffort E N E Product N E N Order N ? ? Party E E E CustRequest E ? ? CommEvent N ? legend: E=existing, N=Needed or Not existing, ?=not sure what the need would be. not existing I think we will need to add a WorkEffortContent entity and CommunicationEventProduct/Order entities. I just threw the note stuff out there to point out that there seem to be three channels for associating "content" with entities - comm events, content and notes. I will be re-evaluating the content management system to see if it can be used to handle more cases without having to add services each time - or atleast try to apply some reuse within those services. I know that the "OFBiz way" is to add functionality as it is needed, but at some point you need to look at refactoring. -Al _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
In reply to this post by davidnwelton
On Thu, 2006-03-23 at 18:55 +0100, David Welton wrote:
> > I am working on a contract that needs these issues resolved. They > > definitely need what Hans was asking for - email attachments saved as > > content entities. If I understand what BJ was saying, I don't think > > relying on an email client to correctly regurgitate an email will do. > > Make sure you test it not only with correct emails, but the nastiest, > most malformed junky spam emails that you can find. There is some > stuff out there that throws weak parsers for a loop, so to speak. My Evolution client recently died on it's feet with such a message, shame I deleted it, perhaps all the spam I get is useful after all! > -- > David N. Welton > - http://www.dedasys.com/davidw/ > > Linux, Open Source Consulting > - http://www.dedasys.com/ > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
In reply to this post by Hans Bakker
Dont forget for item #1, that email addresses can be forged. You won't
want to attach an erroneous communication to a party that they in fact didn't make. Automatic authentication could be troublesome and might probably be better served with some sort of "Incoming Communication Event Authentication Status" like UNCONFIRMED ORIGIN, UNCONFIRMED SENDER, CONFIRMED.... etc. From there some Admin an change the state of an event or dispose of it. Naturally finding the correct partyId could be troublesome too different sender names, different spellings, different cases, unknown contact information for that party, an unknown party. > As of now, I plan on writing services that do two things in the course > of processing an email (in addition to creating the CommunicationEvent): > > 1. Reverse find the partyIds from the fromAddress and recipients. Not > sure about creating skeleton Party/Person/ContactMech entries if they > do not exist. > > 2. Add content attachments to CommEvent. Will create a > CommunicationEventContent entity as discussed in the JIRA ( > > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
In reply to this post by byersa
Hi Al.
Good exiting news! I needed communication events for sending out invoices by email, that is why i got involved with this. It would be really nice if the email itself is stored in the communication event and the attachments as content in the content component and that this communicationevent is connected with all the parties involved on the email. As Si pointed out http://jira.undersunconsulting.com/browse/OFBIZ-665 also has a discussion on this... -- Regards, Hans Bakker ANT Websystems Co.,Ltd (http://www.antwebsystems.com) If you want to verify that this message really originates from from the above person, download the public key from: http://www.antwebsystems.com/hbakkerAntwebsystems.asc On Thursday 23 March 2006 22:23, Al Byers wrote: > I am working on a contract that needs these issues resolved. They > definitely need what Hans was asking for - email attachments saved as > content entities. If I understand what BJ was saying, I don't think > relying on an email client to correctly regurgitate an email will do. > > I will be studying the JIRA issue below more fully and we should be able > to add this feature in the next week. > > -Al > > Si Chen wrote: > > Hans, > > > > We need to expand the entities to have separately stored attachments > > and by extension the services which support them. David and I > > discussed this on the list before: > > http://jira.undersunconsulting.com/browse/OFBIZ-665 > > > > Si > > > > Hans Bakker wrote: > >>On Thursday 23 March 2006 17:45, BJ Freeman wrote: > >>>Not sure why it needs to be changed. > >>>email is sent as text, by default, even multi part email. > >>>binary is converted to text was well. > >> > >>good point, i forgot about that. > >>thanks for your reply...no change required.... > >> > >> > >>------------------------------------------------------------------------ > >> > >> > >>_______________________________________________ > >>Dev mailing list > >>[hidden email] > >>http://lists.ofbiz.org/mailman/listinfo/dev > > > >------------------------------------------------------------------------ > > > > > >_______________________________________________ > >Dev mailing list > >[hidden email] > >http://lists.ofbiz.org/mailman/listinfo/dev > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev attachment0 (196 bytes) Download Attachment |
On Thursday 23 March 2006 20:53, Hans Bakker wrote:
> Good exiting news! I needed communication events for sending out invoices > by email, that is why i got involved with this. It would be really nice if > the email itself is stored in the communication event and the attachments > as content in the content component and that this communicationevent is > connected with all the parties involved on the email. I'm not sure how far you guys want to take this but the dbmail (dbmail.org) project provides some pretty far out database-driven mail storage services. While providing full IMAP style mailboxes might seem like overkill there is an argument that a commercial communication event system will be more heavy-duty than a normal users requirements. -- Ean Schuessler, CTO [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Free forum by Nabble | Edit this page |