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.