1.x-1.2.0

Adds named message templates to the send form.

Until now the only thing the module remembered was the previous send, stored in
one slot per view display and overwritten each time. A message sent regularly
had to be retyped.

A template holds the sender, subject, body and text format under a name of the
user's choosing. "Save as template" on the message form creates one, "Load a
saved template" fills the form back in from it, and saving under an existing
name replaces it, so loading a template, editing it and saving it again updates
it in place. Templates are saved when Next is pressed, so writing one is not a
commitment to sending.

Templates are offered on every view rather than being tied to the display they
were created on, which is what makes a message written once reusable. The
recipient field mappings are deliberately excluded, because a field name from
one view means nothing in another - those stay with the existing "Remember
these values" checkbox, which is unchanged and continues to hold the whole form
for a single display. The view a template was saved from is recorded and shown
in the listing, since a body may still contain tokens another view cannot
replace.

Each template is stored as its own configuration object,
views_send.template.<name>, so templates can be exported and deployed between
sites like any other Backdrop configuration. hook_config_info() declares the
prefix with a name_key, which is what makes core remove them all on uninstall.

A Templates tab under the settings page lists the saved templates with the view
each came from, and deletes with a confirmation.

Also included: the sender, subject and body defaults are now resolved in one
place with an explicit precedence - remembered values, then values carried back
from the preview, then a loaded template. This replaces the two-branch
condition added for issue #18 rather than extending it, and it verifies that
the text format still exists and is permitted to the sender. That last check
hardens the existing paths too: the form's own validation rejects a format the
sender may not use, so offering one made the form unsubmittable with nothing on
screen to explain why.

No schema change and no update hook are required.

Verified with a CLI harness of 49 assertions covering storage, the defaults
precedence, the form, the load handler and the admin pages, and by walking the
form in a browser. The existing harnesses for the 1.2.0 fixes (24 assertions)
still pass.

1.x-1.1.7

Fixes issues with upload and sending of attachments.

Views Send 1.1.6

This release includes the option for additional mail headers (priority; request receipt and others) and also provides a limited capability for multiple file attachments.

Error reporting bug has been fixed and some code reformatted in this release.

Views Send 1.1.5

This release includes the option for additional mail headers (priority; request receipt and others) and also provides a limited capability for multiple file attachments.

Views Send 1.1.4

This release of Views Send provides for the view name to be passed to the Mimemail module so that a custom template can be provided for each view.

Views Send 1.1.3

This release of Views Send removes code that required the Mailsystem module and instead makes direct use of config system.mail.

It adds a dependency on the Mimemail module.

Views Send 1.1.2

This release includes a small fix so that a custom text token can be used in the 'to name' mail field.

Views Send 1.1.1

Views Send provides mass mailing using Views, enabling a list of email addresses to be produced with a view and an email to the group to be composed and sent. HTML-encoded emails may use Mime Mail.

Views Send 1.1.0

Views Send provides mass mailing using Views, enabling a list of email addresses to be produced with a view and an email to the group to be composed and sent.