Symphony.

I wanted to email invoices to clients, from a symphony install where they don’t have member access (so login in and downloading is not an option).

I figured I could use pdfmyurl but then the meta data of the pdf has the page url. The pages that create the invoices may not be public, so users can’t go guessing urls and seeing other clients invoices.

How could this be circumvented, could the invoices (basically just results of a form that is saved as an entry) be created by means of ajax, so there is no changing url scheme?

Otherwise, for the client’s convenience an html email might not be perfect, but a self contained html file as an email attachment (unobtrusive img backgrounds,pure css, or even inline svg) for offline viewing in any modern browser might be good enough….

Does the new 2.2 smtp pear lib extension support attachments, or do I need another lib such as swiftmailer… or what would be the most simple way of sending attachments?

Ofcourse if I stick to normal html email invoices like amazon does, then I can just use the email template filter, without modifying it so that it sends its html as attachment instead of in the body…

I figured I could use pdfmyurl but then the meta data of the pdf has the page url.

If I take an HTML page with a page title, pdfmyurl will use this title instead of the page URL. I don’t find the URL anywhere in the PDF’s metadata. But anyway you should be careful and not expose your client’s data to the public. You might have to write some custom events, but I have to admit that I don’t fully understand how those invoices are supposed to be generated.

Does the new 2.2 smtp pear lib extension support attachments, or do I need another lib such as swiftmailer… or what would be the most simple way of sending attachments?

In Symphony 2.2 the Core Email API supports Plain Text, HTML and attachments “out of the box”. This is why we stopped development of the PEAR Email extension for now. We don’t see any advantage over the core email API.

Documentation will be available on the Symphony website when 2.2 is final. If you like, you can read some work in progress on Github: https://github.com/michael-e/core-email-api-docs .

I don’t find the URL anywhere in the PDF’s metadata.

All downloaded files on macosx have a more info, wherefrom meta in the finder showing the url

how those invoices are supposed to be generated.

I guess with an event saving the form entry and at the same time parsing the result…

In Symphony 2.2 the Core Email API supports Plain Text, HTML and attachments “out of the box”.

Wow , great, then it must also be really easy to setup with critsend or google over smtp, without even using apis
thanks for the doc

So from you exerience with commercial clients, do you feel the cumbersome methods of generating a pdf report serverside justify to just deliver reports as standalone html files?

All downloaded files on macosx have a more info, wherefrom meta in the finder showing the url

I see. Well, yes, that might be a problem if you downlowd the files directly, because OS X will do this. But if you load them in Symphony using an event and then send them via email, those metadata shouldn’t be there.

Wow , great, then it must also be really easy to setup with critsend or google over smtp

Yes, the API even works with gmail (using SSL). :-)

So from you exerience with commercial clients, do you feel the cumbersome methods of generating a pdf report serverside justify to just deliver reports as standalone html files?

I never automatically emailed invoices. In Germany it would be difficult to meet the legal demands, because PDF invoices have to be signed electronically. (I read that this strange rule might be stopped in summer, and I really hope so. Indeed I never understood why PDF should be more secure than printed paper.)

If I would send automatic invoices, I would try and find a PDF solution, simply because you really know how it will look if it is printed. HTML is not as “safe” as PDF in my eyes, because every client might add some stuff to the invoice (like browsers do when printing web pages).