Add the ability for `mailmason` to generate and upload/update templates.

[randytarampi]

See wildbit/grunt-postmark#3 for more details. This is heavily coupled with that PR.

Add an upload task that will generate templates in ./dist and then upload them to a postmark server specified in secrets.json.

I can rejig the README/wiki if we think this is a good idea.

[randytarampi]

bump

Just doing some fall cleaning and saw this was still open. Think we might be able to get some eyes on this soonish @derekrushforth?

[gcoombe]

This would be extremely helpful for me as well. I'm using @randytarampi 's fork for now but it would be great to get back onto master at some point.

[derekrushforth]

Hey @randytarampi,

I'm going to do some thorough testing of both PRs next week. Apologies for getting to this so late.

Thanks for taking the time to do this. This is going to be sweet.

[jmas]

I'm also using @randytarampi 's fork. It will be good if this functionality will be at master and updating with mailmason.

[gcoombe]

Any updates on this?

[chrisbloom7]

I'd like to +1 this, but I also want to call out one problem that we ran into while using Mandrill, which is that some folks were updating templates directly in the UI while others were (as per best practices) updating in our external email template repo and then copying/pasting them over the existing templates. This meant any changes added via the UI were lost. One thing that I had hoped to write but never got around to was a way to do a diff with a pull/push and call out possible conflicts. Might be nice to give that some consideration here, even if just calling it out in the documentation

[randytarampi]

I was actually just about to write up the documentation here when I realized that everything's in the wiki and not the README.

I can add things to the wiki once this gets merged and published but I'm pretty hesitant to add it now while this is still on a branch since it might be misleading.

Do agree that it is a major issue. Caused a couple of headaches in our use case as well – just ended up keeping changes to emails restricted to developers via Mailmason. I can get behind the push/pull diff idea though – sounds like something for another PR based on this though.