v0.18.0

• Added: optimistic-concurrency tokens for editing over an API that may also
  be edited in Mailtea Studio or by another agent. templates.update and
  templates.publish accept base_revision (read from a template's
  revision, now on every template reply); a stale value answers with
  MailteaError (code stale_write, the response body also carrying
  current_revision) and nothing is saved. automations.update accepts
  base_version the same way for graph writes (steps), answering code
stale_version. posts.update accepts base_updated_at (read from a
  post's updated_at, now also returned by posts.update itself), answering
  code stale_write with current_updated_at. All three are optional;
  omit them for today's unconditional write.

• Changed: posts.create / posts.update keep the from (keyword from_=)
  and reply_to you pass, and posts.get returns them (None when the named
  sender or the publication default decides). name is only the post's
  internal name and no longer overwrites the subject. posts.update changes
  only the fields you pass; "" clears name, from or reply_to.

• Note: a from that is not on one of the publication's verified sending
  domains is refused with a 422, and reply_to must be a valid address.

• Docs: automations.activate lists the two cloud-only no_verified_sender
  reasons, CUSTOM_DOMAIN_REQUIRED and the new BUILT_IN_SENDER (a step sends
  from the built-in {slug}.mailtea.email address). No runtime change.

• Breaking: posts.create() with template_id now HTML-escapes the
  variables you pass, the same as every other send. HTML passed in a
  {{key}} value now arrives as visible text, and a value you escaped
  yourself arrives double-escaped. Put {{{key}}} in the template where a
  value is meant to be raw HTML. Variables are now filled in both the
  {{key}} and Visual Email Designer {key} forms. A declared variable you
  do not pass stays in the post with its fallback_value, so the broadcast
  gives each recipient their own value or that fallback, and undeclared tokens
  like {{contact.first_name}} are left for the broadcast too. The post keeps
  the template's published page style, is wrapped in that page, and has its
  show-if blocks decided per recipient when it is sent. Before, only the
  variables you passed were replaced, raw, and only in {{key}} form. It uses
  the template's published version; Mailtea Studio's "Use template" starts
  from the latest saved design instead.

• Changed: templates.update() and templates.restore_version() no longer
  move a published template back to draft. The template keeps its published
  status, and automations and the API keep sending its published version until
  templates.publish() is called again. The template's from and reply_to
  are part of the published version too, so a new sender or reply-to address
  reaches sends only after the next publish. templates.unpublish() is now
  the only way to stop a published template sending, short of deleting it, and
  it drops the stored published version so the next publish starts from the
  current content.

• Added: has_unpublished_versions on every returned template. True only when
  the template is published and its saved content (From, Reply-To and the
  style profile included) differs from the published version.

• Added: is_published on each template version entry: true for the one entry
  automations and the API are sending now. is_current is now described as
  what it is: the entry that matches the working copy (the saved design being
  edited), not necessarily what is sending. is_published is false on every
  entry of a draft, and on a template published before the field existed until
  it is published again.

• Changed: the unpublished field on the update and restore replies is kept
  for compatibility and is now always False. Check
  has_unpublished_versions (or the reply's message) instead.

• Changed (API behavior): a template variable's fallback_value can no longer
  contain { or }. Creating a template with one, or changing a fallback
  to one on update, is a 400 ("Fallbacks can't contain { or }."). A value
  the template already stores is accepted unchanged, so a template saved
  before the rule keeps saving. Inline chip fallbacks such as
  {first_name|Mom & Pop} now render as written instead of double-escaped.

• Changed (API behavior): saving an active automation is refused only when the
  edit adds an error the live version does not already have. The 422
  active_graph_invalid reply's issues lists just those new problems.
  Before, any error refused the save, even one the live version already had.
  Starting refuses every error as before, except an unknown_step_ref at a
  config.* path or a trigger missing_branch that the version the
  automation last ran on already had, so pausing and starting an unchanged
  automation keeps working. Issues the last live version already had come back
  with pre_existing: true.

• Added (API behavior): issue objects carry field, what a rule reads (the
  rule's field, or the path in a {"var": ...} value, e.g.
  steps.welcome.opened) when the issue is about one.

• Changed (API behavior): two issues are the same problem when their code and
  step match, and their field or, when there is none, their path. Moving
  a rule, by removing a rule beside it or putting it in a group, no longer
  makes a problem the live version already had look new. An error is
  pre_existing only if the live version had an error there, not a warning.

• Changed (API behavior): validate_only on an active automation answers the
  way the save would. A trigger change is a 422 trigger_locked_while_active,
  a change that adds a problem is a 422 active_graph_invalid listing only
  the new problems, and otherwise issues come back with pre_existing marked
  against the version live now. Before, it returned every issue unmarked.

• Changed (API behavior): changing the trigger (its type or key) of an active
  automation is now refused with 422 trigger_locked_while_active. Pause it
  first; draft and paused automations can still change their trigger. Before,
  the change was accepted.

• Added (API behavior): new validation rules. A trigger with nothing after it
  is a missing_branch error at branches.next. A rule or {"var": ...}
  value that reads steps.<key>.* for a step that isn't in the automation is
  an unknown_step_ref error at that config.* path, or a warning when the
  {"var": ...} has a default. A rule or value that reads
  event.properties.* when the automation does not start from an app event is
  the new warning event_field_without_event_trigger.

• Changed (API, no client change needed): emails.send(template=...) may
  leave out subject, from_ and sender_id. The template's published
  subject is used, and its sender is the publication's default sender, then
  the template's own From. The send docstring now says so.

• Behaviour (API): the template's variables fill the subject with the same
  values and fallbacks as the body.

---

Released from mailtea-app/mailtea@acea165.