Mechanic now supports publishing to sales channels

Tasks may now publish and unpublish items to any sales channel in Shopify. No special task configuration is needed; simply write GraphQL queries and mutations that address publications.

Example tasks

Mechanic scheduler events now include the current time in {{ event.data }}

All mechanic/scheduler/* events generated now include the current date and time, in the store's local timezone. This value is available in {{ event.data }}, and looks like "2019-10-06T11:30:00-05:00".

The precision of our scheduler has also improved: its events much closer to 0th minute and second (rather than 1-3 minutes after, as was previously the case).

Version 2019-10 of the Shopify API is now in use

Tasks configured with a Shopify API version of "(use latest stable version)" will now call the 2019-10 Shopify API. (Note: this is the default setting for all tasks.)

All "shopify" events now use data serialized by the 2019-10 API.

Notably, the bulk operations API is no longer in beta. This means that tasks may use bulk operations to query Shopify without needing to use the "unstable" API.

Read more from Shopify

Shopify webhooks now use the 2019-07 admin API format

In anticipation of the promotion of 2019-10 to the latest stable version, we're (very belatedly) updating the Shopify API version used to serialize webhook data for Mechanic from 2019-04, to 2019-07. We chose to perform this update now, deeming it better than skipping a version entirely when we move to 2019-10 on October 1.

From Shopify's release notes for 2019-07, the only change that affects resource serialization is the addition of the "admin_graphql_api_id" attribute for many resources.

Event filters now available

Use event filters to conditionally determine which events to process, and which events to skip.

This feature is useful if your account is experiencing (or will experience) a large volume of events that (a) don't need to be processed, (b) would slow down your account if they were processed, and (c) can be programmatically identified.

Read more

Generate zip files for FTP or email

Mechanic's file processing now supports generating zip files, with optional password protection.

This is a part of our standard file processing, which means this feature is available for both "email" and "ftp" actions. And, because you can define the contents of a zip file in Mechanic's standard form, this means that you can generate PDF files, which are then zipped and password-protected, before emailing them or uploading them to an SFTP/FTP server.

Read more

Standardized file generators for "email" and "ftp" actions

While already available for the "email" action, the ability to generate PDFs is now available for the "ftp" action as well. The same file processing is used for both actions, allowing you to be more flexible about how you generate and deliver your material.

Read more

This comes with a small change to the "ftp" action: rather than defining a single file to upload, you can now define as many files as you like, by using a new "uploads" option.

Before:

{% action "ftp" %}
  {
    "host": "example.com",
    "port": 21,
    "user": "anonymous",
    "password": null,
    "put": {
      "mode": "ascii",
      "filename": "example.txt",
      "data": "hello world!"
    }
  }
{% endaction %}

After:

{% action "ftp" %}
  {
    "host": "example.com",
    "port": 21,
    "user": "anonymous",
    "password": null,
    "uploads": {
      "example.txt": "hello world!"
    }
  }
{% endaction %}

The original usage will still be supported, as legacy.

Read more

Tasks: view version history

While Mechanic has always tracked changes to tasks, we now offer this information to users. You can use the version history to see what changed in a task, and when it changed. And, you can restore any older version, allowing you to safely test changes, knowing that you can roll back at any time.

Read more

Event action: specify task_ids

When writing task scripts that include an "event" action, you may now include a "task_ids" option, specifying a whitelist of tasks that are allowed to respond to the new event.

Used in concert with the {{ task.id }} variable, you may now write tasks that queue up future work for themselves, guaranteeing that no other tasks will respond to your events.

Read more

Example

Cache action: positional arguments, new operations

The "cache" action now supports positional arguments, and four new operations: incr, incrby, decr, and decrby.

The existing usage style remains supported. Together, these updates mean that these two styles are equivalent:

{% action "cache" %}
  {
    "incrby": {
      "key": "order_count",
      "increment": 10
    }
  }
{% endaction %}

{% action "cache" "incrby", "order_count", 10 %}

Read more