Option to automatically post newsletters as a new topic

[meelash]

Given the interface where newsletter are sent from the New Topic interface, it seems very natural to have it posted as a new topic. Of course, this is quite easy currently, you can just "Send As Newsletter" and then click a second time and Post it. But if the plugin handles it, the advantage is that the Reply-To address on the mailed newsletter can be the correct one for replying to the topic, and the body of the newsletter can contain a link to the topic on the board as well.

Let me know if you think this is a good idea; I'm willing to work on it.

[yariplus]

Sure! This should be pretty simple.

Probably should add an optional checkbox for "Don't post as Topic", since posting should be the default.

[meelash]

So, the workflow that ended up making the most sense for my use case is actually to move the "Send as Newsletter" functionality inside of an already created topic, thus:

So, to send a newsletter:

1. Some user has to create a new topic and write the newsletter. Other users can proof-read, make corrections, changes, etc.
2. When ready to send, the administrator can open the topic and send the post as a newsletter.

There are a number of advantages to this approach:

• A larger group of users can be in charge of writing newsletters, without having to restrict it only to those that are trusted to send. (this also puts off the immediate need to work on allowing different user groups to send newsletters as proposed in Users/Groups Privileges #38 )
• Multiple users can contribute to writing a newsletter by contributing to the "draft" before it is actually sent.
• You can easily add a link to the topic in newsletter template, allowing users to view it online and/or reply to it.
• Existing functionality can easily be duplicated by creating an admin-only category that no one else can view called "Newsletters" and using it to post and send newsletters. This gives the advantage that you automatically have a history of sent newsletters, without having to do any extra work.

So, in my use case, I have people in charge of several different projects that need to send updates to users, so I just have them post their update as a topic and, when ready, let me know and I send it as an email.

If this workflow seems to make sense, I'm happy to contribute it back. Conversely, if there are use cases I haven't thought about for which it doesn't make sense, or if I can make some modification that makes it more generally usable, that feedback is also welcome.

[meelash]

After testing this, I started to work on fixing sending newsletters from the Admin page by using the same default composer for that. But, then upon further consideration, I don't really see the use for it, given the point above about duplicating the existing functionality (and gaining an automatic history) by just creating a category for newsletters which could be admin-only.
So I removed the admin page completely in my case, if that makes sense. I'm happy to include that also, or not, in any contribution back.

I think in the future we can have use for the admin page for modifying and saving newsletter templates and for setting groups that are allowed to send newsletters.

[meelash]

This proposal is also relevant to #12, since we could add a dropdown or a modal on the topic page that would show, when it had been sent as a newsletter, etc.

[yariplus]

Personally, I like the flow of sending the newsletter from a topic, whether using a new topic or existing. The admin page editor has some additional functionality that I want, but I haven't had time to fix the issues with it.

When sending a newsletter from an existing topic, there would have to be some flag set on the topic that shows it was already sent as a newsletter, to prevent inadvertently sending it twice.

[meelash]

@yariplus Do you think a flag is sufficient? What if the person later wants to send it to a different group from that it was first sent to?
Should we keep a record of when it was sent and to which groups?

[yariplus]

Ideally, we would want to record the date/body/recipients/etc so it can be audited later, but all of that doesn't need to be part of this change right away.