Magento Transactional Email config: best practice - email

Every time I set up a Magento store I must spend an entire day setting up the stupid transactional emails since they are so weak by default.
Half of that time is spent just loading the templates into the backend and clicking around with Magento's user interface...
Is there a straight forward method to load all the emails in one sql statement or similar?
Have any of you found a way to quickly edit all the templates outside of Magento?
Any comments on the email templates adapter extension (or similar)?

Please read about Magento Setup Resources
You can then update your email content/configuration using update scripts in dedicated module, for ex.:
app/code/local/{project_prefix}/ConfigurationEmail

Magento allows you to run update scripts, so you could export the initial setup work and create an EmailSetup module. Note that you would also want to set the appropriate config data to link transactions with the DB emails.
We've made some shell scripts to make regular changes, many of which were obviated by changes which Magento made.
Not familiar.

You should try the Transactional Email extension from Comfirm.
It makes handling transactional email in Magento a lot easier.

Related

Sharepoint Online remote event receiver without App/Add-in

The company I work for uses SharePoint Online. We have a requirement that on most site collections, whenever a user creates a new document library that the document library is configured with the "document" content type being removed, and replaced with some of our own corporate content types.
Previously I've managed this by using a coded sandbox solution installed on relevant site collections which had an event handler that fired on "list added". It's obviously now time to move away from that solution.
I'm really struggling to get to grips with the alternative, conceptually. I'm aiming to replace the old solution with a Remote Event Receiver solution.
The way I think I'd like to achieve this:
1) Create a single remote event receiver hosted in Azure which receives details of a new list being added in a site which it then configures appropriately.
2) Use CSOM to provision the site and as part of that provisioning, hook up the event receiver.
I've spent a lot of time on this, getting nowhere. I initially thought the answer lied in using an App which I could install in the App Catalog and then push out to particular site collections but that doesn't seem to be right.
Is the solution above possible? All examples on the web I've come across of setting up remote event receivers seem to use a SharePoint app which I don't really want to do.
Thanks.
For info I found the answer. You can indeed create a remote event receiver without a SharePoint app/add-in.
The answer was written up here
I thought I needed a SharePoint Provider Hosted App for that part 1
But you should bear in mind that as per Remove event receivers on host web clientContext you will not have the client Context passed through, so
TokenHelper.CreateRemoteEventReceiverClientContext(properties)
...will come through as empty. If you want to interact with SharePoint then you'll need to find another way than this approach, or use a different set of credentials.

CRM 2011 custom Plugin passing parameters to processes

We are trying to automate a few things in CRM and I have an idea about how to go about it while still allowing customizations from the Process section in CRM Settings.
The problem: We receive a lot of E-mails from an account that are added to a Queue. This queue fills up faster than we can clear it. Most of these E-mails have a standard format and the user only has to read a few lines of the the E-mail body to figure out what to do. There's a total of 6 different workflows that the user would do. These haven't been implemented.
Reading the documentation of CRM, I figured that I would need a custom Plug-in that would parse the E-mail body, and trigger a workflow in CRM according to the values in the E-mail. I also need some of the values that the E-mail contains to be passed to the workflow. I already have the Plug-in setup to do this.
The problem I run into is creating a process which takes in custom parameters passed over by the Plug-in I created. I need to access these values in the front-end (one of the Processes in CRM Settings). Is this possible? If not, is there another way to achieve this?
Is there a reason you used a Plugin to kick-off this automation instead of a Custom Workflow (which is a Process)? You could perform the parsing of the E-mail inside your Custom Workflow, and use its InOutArgument properties to pass values into subsequent child workflows.
Definition: https://msdn.microsoft.com/en-us/library/gg327984(v=crm.5).aspx
Sample: https://msdn.microsoft.com/en-au/library/gg334455(v=crm.5).aspx

How to hook 'send email' of IBM Lotus Notes

I'm working on a plugin for IBM Lotus Notes. I need to change content of an email right after user clicks 'send email' button, before the email is actually sent. I have searched APIs of Lotus Notes but can't find a workaround. There is a library named com.ibm.notes.mailsend in folder /opt/ibm/lotus/notes/framework/shared/eclipse/plugins. But I can't find any document related to it on Internet, and have no idea how to capture event about sending email. Does anyone know how to implement the function that I need? Thanks.
Update: Thanks Richard. Basically I've figured out how to hook email sending. But I also need to make an option that user can set differently for each individual email. From my understanding, email known as message is stored in Mail File database before being sent. How to 'add flag' to the message? Thanks.
The way to hook events in Lotus Notes is with the Notes C API's Extension Manager routines. The general strategy for hooking mail send operations is to set up a hook on EM_NSFNoteUpdateMailbox. This can be done on either the Notes client or the Domino Server. On the server side, if your processing is non-trivial, you run the risk of slowing down Domino if you try to do all of the work in your hook, so the strategy most people adopt is to have the hook code change the status of the message to "On Hold" and then signal a separate server task to take over the work. That way the hook can return and the separate server task can take whatever time is needed before resetting the status of the message so that normal routing will take over. You can find documentation here.
For server-side processing only, there are two options that will allow you to write your code in Java instead of C. One is an OpenNTF project called TriggerHappy that allows you to write Java Agents that are fired when some boilerplate hook code is triggered, and the other is the OpenNTF version of the Domino OSGi Tasklet Service (aka DOTS), which allows taskets to be fired in response to EM events. Note that there is an IBM-supported version of DOTS that is shipped in Domino 9 "Social Edition", but my understanding is that it does not include the EM event support.
Updated for additional info requested...
In order to add a flag to each message that can be read by the code that runs in your hook, you need to modify the mail template that is used in the users' mail files. You will need permission from the Domino system administrators to do this, and to be blunt: this is not something that Domino adminisrators like to do because it makes their job more difficult when they are upgrading Domino versions. There are many ways you could modify the template, but the point of all of them would be to add a new hidden field to messages which would serve as a flag for your hook code. If the field exists, your code would do the changes to the content that you need, otherwise it would leave the content alone. One possible way to do this would be by adding a shared action containing a formula to set your hidden field (that formula is just something like FIELD myFlagFieldName := "1";) and then you can add that shared action to the Memo form. Users would press the action button any time they want to trigger your code. The admin would need to maintain backup database containing your shared action and re-add it to the mail template after every upgrade and then re-add it to the new template version's Memo form. Of course there are other ways as well, some that are more friendly to users but harder for admins to deal with, and vice versa.

SugarCrm - How to send e-mail to manager every time a Lead is updated?

I'm new to SugarCRM.
I've google but I can't find a solution for this. Every time a Lead is UPDATED (New Log Call, New Email Attached, New meeting, Status Change) I need to send an e-mail.
How can I do this in SugarCrm?
Best Regards,
André
While the benefits of blasting a person with an email upon every update can be argued against, what you will need to do is use an after_save logic hook on the Leads module. Within that hook you would then send an email if it is an existing lead.
Helpful links:
http://support.sugarcrm.com/02_Documentation/04_Sugar_Developer/Sugar_Developer_Guide_7.6/60_Logic_Hooks/20_Module_Hooks/after_save/
http://developer.sugarcrm.com/2011/02/14/howto-detect-record-state-in-a-logic-hook/
http://developer.sugarcrm.com/2011/03/01/howto-send-an-email-inside-sugar-thru-code/
If you are using professional version you need to create a workflow and customize the email template (everything using sugar interface in admin panel).
If you are using the community version you need to create logic hooks file and create you logic manually. I suggest you create one $old_lead in before save hook and compare this $old_lead with actual $bean and see if have one changes.

Magento Email Templates: Blocks not rendering from adminhtml

I fear I've stumbled into unknown Magento territory. I have exhausted what's left of my Googling abilities and have come up short, so I thought I'd try my luck here.
Our platform is Magento Enterprise 1.9.1.1.
We use an archaic print solution that reads orders via ODBC. As such, we can't have it read from Magento's MySQL database directly (thanks to the high likelihood of change). What I've done is extend Mage_Sales_Model_Order to intercept the _beforeSave() function with direct SQL queries to another database, before returning parent::_beforeSave(). There are likely better ways to have done this, but it's done now, and functional, and regardless it is not where my problem lies.
If any SQL errors are thrown, updates are rolled back and the errors & order data are passed to a function that sends an email to a mailing list with the error information. The email template file in /locale/en_US/template/email/ calls on a .phtml file to process the arrays of data like so:
{{block type='core/template' area='frontend' template='/email/errors/order/beforesave.phtml' orderdata=$orderdata errors=$errors}}
This is functionality I borrowed from /locale/en_US/template/email/sales/shipment_new.phtml. And this is also where I hit my roadblock. The email fires fine from the front end, if errors are encountered when the user is processing an order. If you make order changes from adminhtml, the email is sent, but without the above mentioned block.
I have tried with and without area='frontend' in the block call, and the script exhibits the same behaviour regardless.
I think that the problem may be in my XML, though it finds the template itself just fine from both admin and frontend (and this block is not required to be defined in my XML anywhere). I can also not find any examples of this within Magento's own files, or anywhere on the internet.
Any help would be more than greatly appreciated. This is doing my head in!
Mike
Are you setting the "area" for the actual email template? E.g.:
$emailTemplate = Mage::getModel('core/email_template');
$emailTemplate
->setDesignConfig(array('area' => 'frontend', 'store' => $storeId));
Possible duplicate of sharing template between frontend and backend (admin or adminhtml) in magento.
Don't mean to revive a dead question; just tying up the loose end.
#ColinM: My thoughts were the same as yours, but that somehow didn't work for me. Maybe I don't understand the purpose of setDesignConfig(). Anyhow, the link above worked perfectly for me, in the same scenario as that of the original poster.