Blog

Release announcements, helpful tips, and community discussion

8.2

•

Cerb (8.2) is a feature upgrade released on October 30, 2017. It includes more than 56 new features and improvements from community feedback.

To check if you qualify for this release as a free update, view Setup » Configure » License. If your software updates expire on or after October 30, 2017 then you can upgrade without renewing your license. Cerb Cloud subscribers will be upgraded automatically.

Important Release Notes

  • Always make a backup before upgrading!

  • Cerb 8.2 requires PHP 7.0+ and MySQL 5.6+.

  • To upgrade your installation, follow these instructions.

  • The 8.2 update simplifies the configuration of sender addresses and signatures on groups and buckets. After upgrading, review your groups and buckets to verify that they have properly migrated to the new format.

Custom Records

Create new record types from the browser

New record types can be created from the UI without the need for plugins. Just like built-in record types, custom record types show up in the search menu, worklists, cards, links, custom fields, and itemized permissions in roles.

When creating new custom record types, a singular and plural label can be provided for use throughout the interface.

The possible owners (e.g. app, role, group, and worker) can be configured per record type. A record with no owner types may be edited by anyone. When a record can only be owned by Cerb, it can only be modified by admins and their bots. Custom records owned by roles, groups, or workers are consistent with the behavior of built-in records.

See: Create records for anything without using plugins

For instance, an academic institution can create custom records for courses, instructors, rooms, and students. These can be related through record link custom fields:

You can then create new records with all the same functionality as the built-in records – autocomplete, choosers, cards, popup editors, worklists, profiles, custom fields, bot behaviors, etc:

Use custom records in bot behaviors

  • Implemented bot behaviors for custom record types.

  • Custom records types are now available as targets in Record changed bot behaviors.

Custom Fields

First-class records for custom fields

Implemented cards, choosers, worklists, and profile pages for custom field records. This consolidates custom field management between setup, custom fieldsets, and custom records. It also provides more room for implementing custom field feature requests. Custom fields can now be managed from the global search menu.

On worklists, record link custom fields are now included in the quick search menu. Record links can be searched by ID using a chooser, or with a deep search that can filter by any of the fields of the linked records.

On worklists, columns containing a record link custom field will now open a card popup when available rather than redirecting to a full profile page.

On cards, custom record link fields now open their own cards. Previously these just displayed the text.

Worklists may now be subtotaled by custom record link fields.

Field count on custom fieldset cards

On custom fieldset cards, a search button shows the number of custom fields in the set. Clicking the button displays a worklist of the fields for quick configuration from anywhere.

Reminders

Reminder records with notification behaviors

Added reminders as a new record type. A reminder record has some text, a target worker, a future date, and a list of reminder behaviors to run at that date. These reminder behaviors can be highly reusable and offer public parameters for customization.

For instance, every worker can share the same ‘Remind me by email’ reminder behavior.

By creating a new ‘Custom behavior on reminder’, the possible reminder methods are nearly unlimited (text message, email, notification, webhook, proactive interaction, etc).

A single reminder can run any number of reminder behaviors at the same time.

Reminders can be quickly created from the ‘Links’ menu on any record’s profile page or card popup. This also automatically links the reminder to the current record, and any number of additional links may also be manually added.

As records, bots can easily iterate, create, and modify reminders. Since each reminder has a single target worker, reminder behaviors can always use those placeholders (email address, mobile number, etc).

Reminders have their own profile page, which means every reminder always has a permalink URL that can be used in bot behaviors when sending email or text messages.

A new cron.reminders scheduler job is responsible for running reminder behaviors at the proper time. It is automatically enabled and set to run every minute.

In the past, reminders were implemented using more complex scheduled bot behaviors.

Unlike scheduled bot behaviors, reminders can be rescheduled or snoozed by simply editing them and changing their reminder date. The associated reminder behaviors will be reused and don’t need to be created again.

Create reminders from bots

Bot behaviors have a new ‘Create reminder’ action.

A global bot interaction can assist with creating reminders from any record or card:

A conversational bot behavior can confirm the details and create the reminder directly from the record:

Mail

Group-level mail defaults

Previously, an unnecessarily complex series of cascading defaults was used for mail settings: bucket, bucket reply-to, group inbox, group inbox reply-to, then default reply-to. This made it very difficult for people to understand where the defaults were coming from.

Outgoing mail defaults are now configured at the group level (i.e. send from, send as, HTML template, signature).

When a bucket doesn’t override these values, the group’s values are used.

This is much easier for people to understand, and allows for configuration directly on group or bucket records.

Simplified configuration of sender addresses

When configuring outgoing mail, the separate ‘sender address’ records are no longer needed. Email transports are now directly assigned to email address records to claim them as usable outgoing email addresses.

This simplifies configuration, and allows new outgoing addresses to be created directly from groups, buckets, and other configuration settings.

Email signature records

Email signatures are now their own record type. This makes it much easier to share and manage multiple signatures.

Previously, email signatures were selected through complex cascading rules: bucket, bucket sender, group inbox, group inbox sender, or default sender address.

Configurable automated email templates

The automated email messages sent by Cerb for various events are now completely configurable (i.e. send from, send as, subject, and body). These include new worker invitations, worker new email confirmations, and worker account recovery.

The previous templates included very little body text, which often led to them being flagged as spam. Including the worker and company names in the template can help improve this.

Bots

Create any record from any bot behavior

Added a ‘Record Create’ action to all bot behaviors. This allows a bot to create a record of any type from any behavior based on the permissions of the bot’s owner. Custom records are supported, as are all built-in and custom fields. Unlike the built-in ‘Create’ actions, every field value in this action can be set using placeholders. A dictionary with the new record information (including the generated ID) is returned by the action.

Update any record from any bot behavior

Added a ‘Record Update’ action to all bot behaviors. This takes an input, ID, and changeset as inputs. The changeset is a JSON object keyed on field names. Every field value can be provided from placeholders. The action returns the dictionary for the updated record.

Delete any record from any bot behavior

Added a ‘Record Delete’ action to all bot behaviors. The action takes a record type (context) and ID as inputs. Permission to delete a record is based on the bot’s owner.

Upsert records from any bot behavior

Added a ‘Record Upsert’ action to all bot behaviors. This action takes a record type (context), query, and changeset as inputs. The query is used to determine if a matching record exists or not. When a match exists, the changeset is used to update it. When a match isn’t found, the changeset is used to create a new record. The changeset is a JSON object keyed on dictionary field names. The values of any built-in or custom field can be set using placeholders. Permissions to create or update a record are based on the bot owner. The action returns the dictionary of the created or updated record.

Retrieve any record from any bot behavior

Added a ‘Record Retrieve’ action to all bot behaviors. This action takes a record type (context) and ID as inputs. The action returns the dictionary of the retrieved record.

Search any records from any bot behavior

Added a ‘Record Search’ action to all bot behaviors. The action takes a record type (context), query, and list of keys to expand as input. The query is used to retrieve records, including the new limit:n and page:n filters. The action returns an array of record dictionaries. The “keys to expand” option uses an efficient bulk expansion method across the list of returned dictionaries. For instance, a single query is used to expand organization info on a list of tickets rather than “n” queries for expanding each ticket individually in a loop afterwards. This action is a convenient way to load records without using behavior list variables, when the results don’t need to be used as an ‘On:’ target in another action. The results can still be set on a behavior variable by passing the IDs to a ‘set variable’ query.

API

Records API

Added a new /records endpoint to the API for performing abstract operations on all record types (e.g. create, retrieve, update, delete, search). The record type is specified in the path like /records/tickets/, and aliases are supported in addition to full context IDs.

Custom records are supported. All fields are supported. All of the same validation logic from the UI is enforced in the abstract API (roles, record ownership, etc). This drastically simplifies working with the API.

Previously, each record had to be specifically implemented as an API endpoint, with a limited number of fields, and code that used the API had to hardcode all of those paths.

Upserts

Upserts are now supported in the abstract records API.

An “upsert” is a single operation that updates an existing record when a match is found, or creates a new record when a match isn’t found.

Upserts are performed with a request like PATCH /records/<record-type>/upsert.json. The body has the same format as a PUT update using an array of fields[key]=value.

Upserts require a query parameter with a quick search query that must match exactly 0 (insert) or 1 (update) rows.

For instance, you could upsert an organization with the query name:"Apple, Inc.", and if an organization is found it is updated, and otherwise a new organization is created.

To perform an upsert, a worker must have permission to create and modify records of the given type. They also must have access to update a matched record.

Upserts are particularly useful when synchronizing records into Cerb from a third-party source. For instance, when issues are updated in a bug tracker (like GitHub Issues or JIRA), a webhook could prompt Cerb to pull those changes into a custom record. The upsert query could match on the external ID to determine if a record was previously synchronized or not.

Set complex records fields from the API

  • When creating activity log records, the params field can be provided. This is a JSON-formatted key/value object.

  • When creating calendar records, the params field can be provided. This is a JSON-formatted key/value object.

  • When creating contact records, the email field can be provided. The value is an email address string that will be linked or created as email_id.

  • When creating group records, the image field can be provided. This is a PNG image formatted as a base64-encoded string.

  • When creating message records, the content, headers, and sender fields can be provided. The content field is a text string. The headers field is a text string of Header: value pairs separated by linefeeds. The sender field is an email address string that will be linked or created as sender_id.

  • When creating notification records, the `params field can be provided. This is a JSON-formatted key/value object.

  • When creating snippet records, the placeholders field can be provided. This is a JSON-formatted key/value object.

  • When creating ticket records, the participants and status fields can now be provided. The participants field is a comma-separated list of valid email addresses. The status field must be one of: open, waiting, closed, or deleted.

  • When creating worker records, the image field can be provided. This is a PNG image formatted as a base64-encoded string.

  • When creating workspace list records, the params field can be provided. This is a JSON-formatted key/value object.

  • When creating workspace widget records, the params field can be provided. This is a JSON-formatted key/value object.

User Interface

Improved usability on the global search menu

The global search menu now opens with three columns, rather than one potentially very long column that requires scrolling the entire page (especially with the introduction of custom records).

We renamed some record types so they’re grouped together for quicker access (e.g. email mailboxes, email signatures, email transports).

In a near-future update, we intend to add frequently accessed record types to the top of the search menu, with a “more” link to expand the less common options.

Confirmation when closing editor popups

When closing an editor popup with the <ESC> keyboard shortcut, a confirmation message is now displayed (i.e. “Are you sure you want to close this editor without saving?”). This allows workers to keep the editor open if closed unintentionally.

This is currently implemented for compose, comments, and bot behaviors. It will soon be implemented for all editor popups.

Improved usability when resizing popups

Improved the usability of popup windows everywhere in Cerb. Previously, resizing or moving a popup broke its automatic height adjustment when its contents changed. The popup height is now recalculated after every drag or resize event.

Improved usability when editing roles

When editing roles, the privileges on the ‘Records’ tab are now displayed in two columns to reduce the amount of vertical scrolling required.

Improved usability on profile pages

On profile pages, the Links menu is now displayed in three columns to reduce the need for vertical scrolling.

Cards

Added cards for more record types

Implemented cards, choosers, worklists, and custom fields for:

  • API credentials

  • Email mailboxes

  • HTML templates

  • Knowledgebase articles

  • Knowledgebase categories

  • Mail transports

  • Webhook listeners

Packages

Import records and relationships

Packages can now create nearly any kind of record, along with complex relationships between records.

Previously, packages were limited to a few hard-coded record types (bots, custom fields, workspaces, etc).

This enables packages to configure and populate nearly any feature in Cerb.

We’ll be demonstrating this with the upcoming comprehensive Evaluation Package. It includes project boards, workspace dashboards, worklists, sample tickets, sample contacts, and much more.

Setup

Simplified incoming and outgoing mail configuration

On the Setup page, the Mail menu has been simplified with two sections for Incoming mail and Outgoing mail. Each section is divided into tabs that are sequentially ordered (e.g. create transports, assign transports to sender addresses, assign sender addresses to buckets).

Previously, there were a dozen options in the mail menu without any clear sequence between them.

Added a Team shortcut menu

On the Setup page, a new Team menu is available for quickly setting up roles, groups, and workers.

It was possible to do this from the global search menu, but this wasn’t intuitive for new users.

Shorter duration options for session expiration

In Setup » Security, added new shorter duration Session Expiration options for: 15 mins, 1 hour, and 2 hours.

Portals

When setting cookies for community portal sessions, we now set the secure flag when SSL is in use. This helps pass PCI-DSS compliance checks.

Installer

Conversational bots, project boards, and webhooks are enabled by default

The installer now automatically enables the following plugins:

  • Conversational Bot Portal for Public Websites
  • Project Boards
  • Webhooks

These important features will now “just work” without having to be installed and configured first.

Default signature

The installer now creates a default signature and links it to the first sender address.

Previously, there wasn’t a default signature, and it wasn’t immediately obvious to new users how to create one.

Developers

Custom placeholders in the template editor popup

The template editor popup is now capable of displaying custom placeholders along with those from a given record type. This reusable template editor simplifies the UI by not embedding a full script editor with a placeholder menu for every field that needs one.

Previously, the template editor could only display one record type worth of placeholders (e.g. worker placeholders when editing a signature template).

Platform

These popular plugins are now bundled with Cerb as features:

  • Conversational Bot Portal for Public Websites
  • Project Boards
  • Webhooks

Previously these plugins could be found in the Plugin Library, but it wasn’t obvious to new users that they were available.