Cerb

Release notes for Cerb 6.5 Cerb (6.5) is a major functionality update released on September 20, 2013. It contains over 144 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.5 Core [CHD-3425] [Virtual ... [More] Attendants/Code Cleanup] Fixed a PHP error regarding "Undefined variable: func in abstract_view.php" when Virtual Attendant behaviors contained list variables with a specific combination of parameters. [Contacts/Snippets] Fixed an issue where the names of Contact Person records always displayed '(contact person)' in snippets and Virtual Attendant placeholders. [Virtual Attendants/Variables] Virtual Attendant behavior variables now support parameters based on each type of variable. This provides more control over how they operate, and it also makes new variable types possible (like a picklist of pre-defined options). [Virtual Attendants/Variables] Text-based Virtual Attendant behavior variables can be configured for single-line or multiple-line input. Previously, all text variables were single-line input, which made it difficult to enter certain kinds of data (e.g. long comments). [Virtual Attendants/Variables] Virtual Attendant behavior variables can be reordered by dragging them in the UI [Virtual Attendants/Variables] Virtual Attendant behaviors may specify picklist (drop down) variables. Picklists require a worker to pick an option from a list of predefined options. Previously, only freeform text entry was available. This is particularly useful for macro behaviors. [Snippets/Tester/Usability] The snippet tester now displays output with a fixed width font that preserves whitespace. Previously, tester output stripped whitespace. This made it impossible to check the style of indentation (e.g. at the beginning of paragraphs, or in fragments of code). [Virtual Attendant/Usability] The Virtual Attendant action for entering custom scripts no longer auto wraps the contents of the text box. This makes it easier to read source code. [Virtual Attendant/Simulator/Usability] Added an indent to the form elements in the Virtual Attendant Simulator to improve readability. [Virtual Attendants/Simulator/Variables] The public variables of Virtual Attendant behaviors may now be changed from within the simulator. This makes it much easier to test macros. [Comments/Snippets] Implemented two new placeholders for comment records. The record_watchers placeholder is a list of watchers on the record containing the comment. The record_watchers_emails placeholders contains a comma-delimited list of watcher email addresses. This was requested by several people who wanted a way to relay an email to all watchers about comments on records of any type using Virtual Attendants; however, it can also be used to display a list of watchers anywhere the comment is referenced. [Plugins/Choosers] Choosers can be opened in 'single selection' mode, where the first selection closes the chooser and returns control to the caller. This provides all the benefits of choosers for situations where a single record must be selected. [Virtual Attendants/Simulator/Usability] The output of the Virtual Attendant simulator no longer has a maximum height before introducing scrollbars. Having multiple scrollable sections made it more difficult to read the output or to scroll down the page. [Virtual Attendants/Simulator] When using the Virtual Attendant simulator, it is now possible to choose the exact record that the current behavior is being tested against. Previously, the simulator would choose random records to help test behaviors, but this often required opening up the simulator many times in order to find a suitable record. For macros, it was possible to run the simulator from a record profile in order to test using that record, but this option wasn't available to events like 'New message on a group conversation'. [Virtual Attendants/Simulator/Usability] In the Virtual Attendant simulator, data entry for parameters and values have been moved to tabs. When a behavior provides parameters (public variables for entry by a worker), the parameters section is shown by default and the long list of values is hidden on a second tab, which improves usability by reducing clutter. [Virtual Attendants/Snippets] Implemented a new json_decode() function for snippets and placeholders to convert a JSON string to an associative array. This can be used to easily reference JSON results from API calls within Virtual Attendant behaviors (or snippets in special situations). [Virtual Attendants/Snippets] Implemented a new json_pretty filter for snippets and placeholders to optimize the human readability of a JSON string. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Virtual Attendants] Virtual Attendants are now first-class records (like groups and workers), with worklists, profiles, peek, ownership rights, etc. Previously, Virtual Attendant behaviors were owned directly by roles, groups, and workers; but this was creating clutter and confusion because some behaviors are related but there was no indication of this in the UI. Now, multiple Virtual Attendants can be created to contain any number of behaviors, and each VA can be owned by a worker, group, or role. All existing behaviors have been migrated to a new default Virtual Attendant record for each distinct owner. Virtual Attendants now show up in the global 'Search' menu, and clicking into a VA profile is where you will find the behavior trees and scheduled behavior. This also provides many new possibilities for future expansion; for example, Virtual Attendants can log errors to their profile in an easy-to-find tab. You can export and import behaviors between Virtual Attendants to place related behaviors together. [Messages/Performance/Snippets] The placeholder for message content is now lazy-loaded only when it is needed. This reduces extraneous queries from hitting the database when Virtual Attendants or snippets use message fields but ignore content. [Virtual Attendants/Macros/Profiles] The 'Virtual Attendants' button on profiles now organizes behaviors by Virtual Attendant. This makes it much easier to find the behavior you're looking for. Additionally, the macro menu no longer displays two lines for each entry; instead, behaviors are indented below their Virtual Attendant. This allows more options to be displayed in a smaller space, and it's less visually confusing. [Virtual Attendants/Activity Log] Activity Log entries that are created in response to Virtual Attendant actions will now log each Virtual Attendant as the actor. Previously, these entries were created as if the behavior's owner (e.g. worker, group) had performed them, which could lead to some confusion of accountability. Since Virtual Attendants are now first-class objects, they can be held accountable individually for actions they take. The Activity Log will also specify the name of the responsible behavior next to the Virtual Attendant. [Debug/Virtual Attendants] The /debug/export_attendants page will now export all behaviors grouped by Virtual Attendant. [Virtual Attendants/Scheduled Behavior] The 'Scheduled Behavior' tabs have moved to Virtual Attendant profiles. Previously, scheduled behavior was shown on worker and group profiles, since those records directly owned behaviors. The records targeted by scheduled behavior still show a summary at the top of their profile. [Mail/Reply/Virtual Attendants/Macros] The 'Virtual Attendants' button that is displayed when replying to a message will now display macros grouped by Virtual Attendant. [Setup/Virtual Attendants] The 'Setup->Configure->Virtual Attendants' page now displays a worklist of Virtual Attendants with links to profiles. Previously, a funky interface was used that required an admin to pick an owner from a list to view their owned behaviors in a tab. The new process is consistent with the way the rest of Cerb works. [Virtual Attendants/Snippets] Implemented a new jsonpath_set() function for snippets and placeholders to dynamically create deeply nested JSON objects from inside scripts. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Setup/Mail/Filtering/VAs] The Setup->Mail->Filtering page now shows the mail filtering behavior from all global Virtual Attendants on a single page. Previously, it was only possible to have a single global Virtual Attendant and its use was implied on this page. [Setup/Mail/Filtering/VAs] When an admin views the Setup->Mail->Filtering page for the first time, Cerb will offer to create the first global Virtual Attendant if one doesn't exist already. This improves the onboarding experience. [Virtual Attendants] Virtual Attendants may now be disabled, which treats all of their behaviors as being disabled. These behaviors will not trigger during events, and will now show up as macros on profiles. This makes it very simple to simultaneously deactivate related behaviors, which was tedious in earlier versions. Additionally, a worker can disable a Virtual Attendant while building and testing its behaviors. [Activity Log] Activity Logs for actor profiles (address, worker, group, virtual attendant) now display entries where the record was either an actor or a target of the activity. Previously, the log only showed actor activity for those records, and target activity for everything else. This meant that when viewing an address's activity from its profile, you wouldn't see log entries for when that address replied to conversations (as an actor), only when workers performed actions on that address (as a target). This change provides a more comprehensive view of the activities a record was involved with. [Activity Log/Groups] Group profiles now display an Activity Log tab. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can own custom fieldsets, providing them with long-term storage for arbitrary data on any record. This enables some very interesting new automation workflows. For instance, a monitoring Virtual Attendant can remember the last time it notified each worker about something by using a custom fieldset with a date on worker records. Similarly, a sales Virtual Attendant can keep track of its progress through an automated sales process with a custom fieldset that it saves on opportunities. [Virtual Attendants/Macros] Application-owned Virtual Attendants can now create custom behaviors for any record type. This allows global macros that are accessible by all workers, which greatly simplifies many workflows. Previously, these macros could only be created by VAs owned by groups, roles, or workers. [Virtual Attendants/Macros] Implemented a 'Custom virtual attendant behavior' event. This is the ideal place to implement generic behaviors that don't rely on a specific record type. For example, a Twitter Bot could schedule a recurring behavior to look for new @mentions, and it wouldn't make sense to target this behavior to any particular record. Previously, we had recommended to bind these generic behaviors on worker records just because it made them easy to manage from a profile. Now we recommend that these behaviors be migrated to Virtual Attendant profiles. [CHD-3113] [Support Center/Logins/Usability] When a Support Center page requires a login, a visitor will be redirected to their original destination after successfully logging in. Previously, the Support Center didn't even provide a login form to anonymous visitors if they requested a protected resource, it just displayed the default page. The new process should make it much easier to send contacts direct links to a specific ticket history, or protected knowledgebase articles. [Support Center/Usability] By default, the logo image on the Support Center is now a shortcut link back to the default page. [CHD-3441] [Support Center] When a customer views a ticket in the Support Center, there is now a reply button per message and no reply from is shown by default. Previously, a single reply form was always displayed at the top of the ticket which led to much confusion. [CHD-3148] [Support Center] When a customer replies to a ticket in the Support Center, the original message will now be automatically quoted in the response. [Platform/Popups/Usability] Popups are now limited to a height no more than 85% of the current browser height. Previously, popups could be so tall that they scrolled off the page. This made them difficult to work with; particularly when dragging them around. [Virtual Attendants/Macros/Plugins/Platform] Any Virtual Attendant behaviors that respond an event trigger will now be returned along with a snapshot of their data at their conclusion. This allows the caller to retrieve detailed information from those responders, and in an arbitrary way. [Virtual Attendants/Actions/Run Behavior] Virtual Attendant behaviors may now use a global '(Run behavior)' action. This is similar to 'Schedule behavior', except it runs the behavior immediately and allows the caller to retrieve values from the delegate behavior. For example, if one Virtual Attendant delegates another VA's behavior in order to create a task, then the caller can afterwards retrieve information about the created task from the delegate. This greatly improves the reusability of Virtual Attendants, as specialized VAs can handle routine actions, and helper VAs can delegate requests to them. This also makes it possible to build mediator VAs that listen on channels like SMS, IM, and Campfire; with requests being delegated to VAs that can do almost anything possible in Cerb: send reminders; create and complete tasks; check and change calendars; interact with Twitter, Facebook, JIRA; etc. [Virtual Attendants/Scheduled Behavior] Fixed an issue with the 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants. Disabled behaviors were not included in the list of available options, so if the actions referred to a behavior while it was disabled, and that action was edited and saved, then it would no longer refer to the behavior afterwards. Disabled behaviors are now displayed in the action, but they're marked as being disabled in case this is unintentional. [Virtual Attendants/Actions] When a Virtual Attendant action is missing, the behavior editor will now provide more helpful information, including an indication of what it was supposed to be. Previously, a blank action box was shown without providing any clue about what was missing. [Support Center/History/Reply] Fixed warnings created by the Support Center when a customer replies to a ticket without any attachments. [Virtual Attendants/Actions/Variables/Usability] In Virtual Attendants, the actions for setting variables are now displayed at the top of the available actions. As with other global actions, they are surrounded by parentheses. Previously these were sorted alphabetically with other 'Set' options, which made them more difficult to find. [CHD-1050] [Worklists/Custom Fields] When displaying a multiple value custom field as a worklist column, all of the selected values will now be displayed. Previously, only a single value per custom field was displayed based on what matched the search filters. [CHD-1086] [Custom Fields/Attachments] Implemented two new custom field types: file and multiple files. These types allow arbitrary attachments to be attached to records through custom fields. Internally, these fields use the attachments system and they store file IDs. [Virtual Attendants/Scheduled Behavior] The 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants are now global. They are available in all events and plugin-provided events do not need to implement them. Additionally, the action names are wrapped in parentheses so they appear at the top of the list of available actions. [Custom Fieldsets] Custom fieldsets may now be owned by the application. These fieldsets are readable by all workers but only configurable by admins. [Virtual Attendants/Custom Script] The 'custom script' condition in Virtual Attendant outcomes now a placeholders menu and script tester. [Calendars/Virtual Attendants] Calendar records can now also be owned by Virtual Attendants or the Application. [CHD-3460] [Virtual Attendants/Calendars] All Virtual Attendant behaviors may now use 'calendar availability' as a condition in outcomes. For example, this can be used to send different auto-replies based on availability. [CHD-2866] [Virtual Attendants] The 'new message on a watched conversation' event will now always include a ticket's owner even if they aren't a watcher. [Setup/Localization] A Setup->Configure->Localization page has been added for selecting the default date/time format for everywhere dates are displayed. Admins can choose between 12hr or 24hr formats, and this selection will cover all workers that don't have an established preference. [CHD-3064] [CHD-2973] [Preferences/Localization] Each worker can choose their desired time format (12-hour or 24-hour) from the 'Settings' page in their worker menu. [Virtual Attendant/Events] Added a new application-level 'Before sending worker message' event. Previously this was only possible at the group level. [Virtual Attendant/Events] Added a new application-level 'After sending worker message' event. Previously this was only possible at the group level. [CHD-3340] [Virtual Attendants/Mail] Virtual Attendant behaviors on the 'Before sending worker message' event may now add custom mail headers to the outgoing message. This was requested as a way to force read receipts, among other workflows. [Virtual Attendants/Behaviors] Virtual Attendant macro behavior may now be marked as public or private. A public behavior is visible to everyone with access to the VA (on profiles, etc). A private behavior is only visible to the VA itself. Private behaviors are useful for implementing helper macros within a VA that shouldn't be exposed to the outside world. These are generally used from 'Run behavior' or 'Schedule behavior' actions. [Virtual Attendants/Permissions/Events] Admins can choose which events each Virtual Attendant is capable of creating behaviors for. The options are 'allow all', 'allow these:', and 'deny these:'. This provides a way to offer limited Virtual Attendant functionality to workers with all use cases requiring prior approval. After the upgrade, all existing Virtual Attendants will default to 'allow all' events. [Virtual Attendants/Permissions/Actions] Admins can choose which plugin-provided actions a Virtual Attendant is capable of using in behaviors. The options are 'allow all', 'allow these:', and 'deny these:'. For example, the actions for JIRA and Twilio may be restricted to admin-controlled global VAs that worker VAs can delegate to. Actions that directly communicate with external apps and services can be restricted from use by most workers. After the upgrade, all existing Virtual Attendants will default to 'allow all' actions. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can specify a format for its output of either 'text' or 'JSON'. JSON output will be automatically be converted to an object when it is saved to a placeholder. This is particularly useful to simulate JSON responses from actions that perform API calls. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can be configured to only set the placeholder when in simulator mode. This assists with providing test data in the simulator without affecting the outcome of a behavior when it runs normally. [Virtual Attendant/Simulator] Public worklist variables in Virtual Attendant behaviors can now be tested properly in the simulator. [Virtual Attendants/Actions] The 'Schedule behavior' and 'Run behavior' actions in Virtual Attendants can now include placeholders in the parameters being passed to the other behavior. [Virtual Attendants/API] Implemented '/rest/va/list.json' in the Web API for retrieving the list of Virtual Attendants that are visible to the current worker. This can include an 'expand' parameter with the option 'behaviors' to list all of the defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/123.json' in the Web API for retrieving the a particular Virtual Attendant. This can include an 'expand' parameter with the option 'behaviors' to list all of its defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/behavior/123/run.json' in the Web API for running a 'Custom API request' Virtual Attendant behavior. This provides a standardized way for external applications and services to communicate with Virtual Attendants in Cerb. For example, a Campfire Bot can listen for messages in a chat room and relay a specific pattern (e.g. "@Cerb do something") to a specific VA behavior through the Cerb API. The response is a dictionary of all the behavior's values after running, including public and private variables. If a behavior retrieves a list of tickets, then their details will be available in the response for use outside of Cerb. [Virtual Attendants/API] Added a new 'Custom API request' event to Virtual Attendants. This can be utilized by app-owned and worker-owned VAs. These behaviors work similarly to macros, except they are only triggered through the API from external apps and services. This allows for interaction with Virtual Attendants through mobile text messages, email, instant messages, Campfire/Hipchat, mobile applications, browser plugins, etc. Custom API request behaviors always target the owning Virtual Attendant, and they provide an 'Add to API response message' action that appends text to the _response value of the API response. Using the _response value is optional, but it provides for generalized interaction with Virtual Attendants through the API. For example, an iOS app could display a list of all Virtual Attendants and their API-enabled behaviors. Running any behavior could prompt for its public parameters, and the response message could be displayed. It's also possible to use the 'custom placeholder' action for additional outputs. [Virtual Attendants/API] When a Virtual Attendants dictionary is converted to an array (e.g. for use by the Web API), any nested dictionaries will also be converted to arrays. Previously, if a behavior contained extra dictionaries (e.g. a list of records from a worklist search), it would return the IDs of those records but not their values. [Virtual Attendants/Simulator] When simulating the Virtual Attendant 'Run behavior' and 'Schedule behavior' actions, the simulator output will now show behavior variables being set. [Virtual Attendants/Simulator] Implemented Virtual Attendant simulator output for the 'Send email to notified worker' action in 'New notification for me' behaviors. [Setup/Mail/Parser] Raw email messages can be imported from Setup->Mail by pasting them into a textbox. This simplifies development, training, and evaluations. Previously, these messages had to be saved in the /storage/mail/new/ directory and then the parser scheduler job had to be manually run. [CHD-957] [CHD-3037] [CHD-3173] [Setup/Mail/Parser] Incoming mail messages that failed to parse can now be viewed, retried, or deleted from the Setup->Mail->Failed Messages page. Previously, administrators had to proactively monitor these files on the disk in the /storage/mail/fail/ directory, occasionally move them to /storage/mail/new/, and run the parser scheduled job manually in order to inspect the output. Failed mail is now displayed in a familiar worklist format with a peek popup to view each message source. [Web-API/Usability] Added a QR code image to the Web API Credentials peek popup. This allows mobile apps to quickly scan the QR code to copy the access and secret keys rather than requiring a user to laboriously type them. [Contexts/Messages] The generic label for Message records now shows the sender email, ticket mask, and ticket subject. Previously this just showed an unhelpful '(message)' placeholder. The label is used in Virtual Attendants, the Web-API, and the mobile app. [Contexts/Activity Log] Activity Log contexts now provide actor_* and target_* placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Activity Log] Activity Log contexts now provide a human-readable 'event' placeholder to describe the activity being logged. This can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Workers] Worker contexts now provide is_disabled and is_superuser placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Snippets/VAs/Workers] Added 'last activity date' to worker placeholders. [Devblocks/Workspaces/Charts/Plugin Development] The Devblocks HTML5 charting library now mediates all mouse interaction with the charts. Listeners can bind to 'devblocks-chart-click' or 'devblocks-chart-mouseover' to receive updates about user input. The returned event includes information about the closest data point to the mouse cursor, including chart coordinates. This saves the caller a lot of work when designing interactive charting elements. [Workspaces/Dashboards/Line Charts] Line chart dashboard widgets now display a horizontal line through the selected data point to make lateral comparisons easier. [Workspaces/Dashboards/Scatterplots] Scatterplot dashboard widgets now display crosshairs that intersect at the selected data point. This makes comparisons easier in both dimensions by creating quadrants. [Workspaces/Dashboards/Gauges] Gauge dashboard widgets now display their labels below the widget for uniformity. [Virtual Attendants/Variables/Lists] When a Virtual Attendant behavior has a list variable, the resulting worklist view_id will now be saved in the dictionary in the format var_name_view_id. This allows reuse of the underlying worklist for all kinds of functionality. Notably, it's currently used to send worklists to the mobile app. It could also overcome the 100 object limit of list variables now. [Calendars] Fixed an issue where long-running calendar events that started before and ended after the current month wouldn't be displayed as spanning the entire month. [Platform/Contexts/Plugins] Added a getPropertyLabels($dictionary) method to Extension_DevblocksContext extensions. This provides more terse human-readable text for labels when dictionaries are used on worklists and profiles (particularly in the mobile interface where spaces is limited). For example, "Ticket initial message sender address" can be abbreviated to "First wrote". [Mail/Display] Fixed an issue when displaying tickets where very long messages (i.e. over 1MB) could cause a PHP timeout before the page was displayed. This was caused by attempting to auto-hyperlink URLs found within the email message, and it was exacerbated if 'read all' mode was always enabled when reading tickets. Cerb will no longer attempt to auto-hyperlink URLs within messages that are greater than 512KB in length. [Platform/Plugins/Search] Devblocks now provides an OPER_CUSTOM operator for DevblocksSearchCriteria objects. This allows the caller to provide their own WHERE clause. For example, in some situations a query needs to modify a value before doing a comparison on it (e.g. fieldvalue+5 > otherfield_value). [Devblocks/Placeholders/Usability] The 'devblocks_prettytime' modifier in placeholders now outputs 'just now' instead of '0 secs'. [Calendars/Datasources/Performance] On calendars, worklist datasources were previously inconsistent in that the 'end date' could use placeholders while the 'start date' required a specific date field. This option was provided so that events could be arbitrary lengths; however, it wasn't possible to efficiently determine the events that needed to be displayed for a given month because the placeholders would have to be evaluated for every record in the database. In order to fix this issue, the 'end date' for worklist datasources on calendars now requires an explicit date field. Event durations can be set by using the new 'offset' fields for the start and end dates. For example, an event can end using the same field as the start date, but with a "+2 hours" offset. These offsets are much more efficient to process algorithmically in the database than open-ended placeholders. [CHD-3515] [Calendars/Datasources] Fixed an issue with displaying worklist records on calendars when the events didn't start and end within the same calendar month. For example, if an event started on August 31 2013 and ran for 3 days, it wasn't being displayed on the September calendar. [Virtual Attendants/Actions/HTTP Requests] A new 'Execute an HTTP request' action in Virtual Attendants allows them to send and receive data with other apps and services. The results of an HTTP request are stored in a custom placeholder that can be used by subsequent outcomes and actions. JSON responses are automatically converted to an object. Image resources as a response (e.g. PNG, GIF, JPEG) are converted to base64 text. For example, when new mail is received a Virtual Attendant could send relevant details to an external URL (like a webhook). A behavior could also request information from any source as a URL; e.g. datacenter temperature, website traffic, monitoring metrics, etc. Mobile plugin [CHD-1056] [CHD-1108] [CHD-2378] [Mobile/Plugins] A 'Mobile Interface' plugin has been added to the Plugin Library. We had originally held off on creating a mobile interface because most workers use desktop computers and Cerb's UI workflow design is heavily dependent on multiple layers of popups to enable multiple actions from the same page. With the introduction of custom workspace pages in 6.0 and distinct Virtual Attendants in 6.5, the components of a mobile interface clicked into place. Rather than seeking to replace all the functionality in Cerb's normal UI, the mobile UI provides a access to previously curated content. The primary focus is on providing access to notifications, workspaces, and special Virtual Attendant mobile behaviors. The mobile plugin is built using jQuery Mobile, so there is a large list of supported devices: iPhone, iPad, Android, Windows Phone, Blackberry, WebOS, etc. We feel that a slim web interface is an ideal mobile strategy for Cerb because the functionality is contained within a plugin that is always in sync with the version of the main project. With mobile apps in various app stores using Cerb's API, users would constantly run into issues with version incompatibilities. Once logged in, the mobile interface can be accessed from any mobile browser by visiting the '/m' page at your normal Cerb URL. This can be bookmarked or saved to your device's home screen. [Mobile] Notifications can be viewed in the mobile interface. At the moment they open up a new browser tab to the full Cerb UI. In the near future we plan to implement mobile-friendly profiles for all record types. A count of unread notifications is displayed on a badge at the bottom of the app. [CHD-891] [Mobile/Workspaces] Workspaces can be viewed in the mobile interface. All workspaces that the current worker has access to will be displayed. The worker is prompted in several steps to select a workspace, a tab, and finally a worklist or a widget. The pages for tabs, worklists, and widgets provide shortcuts to jump back to the previous selections (for instance, from a widget to a page or tab). A filter box above the list narrows down the choices (for example, only showing pages with a specific owner). At the moment, clicking on a worklist row opens up the record in the full Cerb UI in the default browser. [Mobile/Virtual Attendants] Added a new 'Mobile behavior' event to Virtual Attendants. These behaviors can be run from mobile devices for any kind of workflow. For instance, mobile behaviors can create or search tickets, create tasks or notifications, search external systems for information, etc. Any public behavior variables will prompt the current worker for additional information. These behaviors can also be implemented on app-owned VAs so they are available to all workers by default. Mobile behaviors can respond with various types of messages that are displayed in a mobile device (e.g. text, html, maps, etc). [Mobile/Virtual Attendants] Virtual Attendants with mobile behaviors can be viewed in the mobile interface. All VAs that the current worker has access to will be displayed. When a Virtual Attendant is selected, a list of its available mobile behaviors is displayed. Selecting a behavior will prompt for the input of any public behavior variables (for instance, a mobile behavior to create a task would prompt for the task's name and due date). The response from the Virtual Attendant is displayed in a message reminiscent of a chat bubble. This functionality is incredibly powerful; Virtual Attendant powered mobile behaviors can provide workers with shortcuts to accomplish almost any workflow. Those behaviors are built inside Cerb's normal web interface. [Mobile/Plugin/iOS] The Cerb mobile interface now supports being added to the iOS home screen as a web app. This removes the location bar and footer from Mobile Safari so the experience feels more like a native app. Device-specific icons and start screens are provided (e.g. iPhone, iPad, retina). [Mobile] Implemented a sidebar panel in the mobile interface. This provides access to more functionality than can fit in the footer shortcuts: favorites, compose, pages, search, etc. [Mobile/Workspaces/Pages] The mobile interface now provides access to both workspaces and pages. The distinction is that a workspace is a page added by a worker to their navigation menu. Pages represent everything that a worker could choose to add to their menu as a workspace. [Mobile/Workspaces] The Workspaces shortcut in the mobile footer now displays a worker's workspaces in the same order that they appear in the full site. Previously this was displaying a list of all pages in alphabetical order. [Mobile/Profiles] The mobile interface now provides a profile page for every record type in Cerb. This makes it possible to gather more information without leaving the mobile site. Profiles also provide automatic links between related records. For example, from a ticket profile you can quickly view the sender's profile, their org's profile, the assigned group's profile, the ticket owner's profile, etc. [Mobile/Search] The mobile interface now provides a 'Search' page in the menu panel. This displays a list of every record type in Cerb. When a record type is selected then a mobile worklist is displayed with the matching records. Clicking on a record displays its mobile profile. The profile also contains a link to open the record in the full site. This improvement makes the mobile interface very useful for workers who need to perform quick record lookups while away from their desk. [Mobile/Workspaces] Mobile worklists now display their current filters above the list. Clicking a filter removes it. [Mobile/Workspaces] New filters can be added to mobile worklists using quick search functionality. Clicking the filters button above the list opens a popup that displays all searchable fields. [Mobile/Workspaces] Mobile worklists can use existing filter presets. After clicking on the filters button, all presets are displayed as buttons in a popup. Clicking one of these buttons will instantly replace the filters. This is particularly useful in a mobile environment, especially when performing ad-hoc searches rather than using prebuilt workspaces. [Mobile/Workspaces] Mobile worklists can be sorted in ascending or descending order on any available column. The field currently being sorted by is displayed above the list, and the arrow next to the label indicates the sort direction (i.e. asc, desc). [Mobile/Workspaces] Mobile worklists can be paged forward and backward. On subsequent pages, an option is provided to instantly jump back to the first page. In a slight deviation from the full UI, paging displays the current and total pages along with the total number of results. In the full UI, paging displays the current position in the results and the total number of results (i.e. no indication is given for the total number of pages). [Mobile/Workspaces] Mobile worklists can now display any number of fields for each row. Since screen space is generally limited on mobile devices, these fields are not displayed as horizontal columns like in the full UI, but as smaller vertical rows beneath each result's heading. At the moment, the displayed fields are based on useful defaults for each record type. In the near future this feature will support the ability to decide which fields should be displayed per worklist or worklist type. This functionality is actually more advanced than the main UI, since it uses the placeholders from Virtual Attendants and snippets instead of being confined by the results from the database. In the main UI, only a limited amount of information from related records is available as columns (e.g. ticket -> organization). With the placeholder approach, even content at the end of a long chain of related records can be displayed (e.g. ticket -> first message -> sender -> org -> custom field). [Mobile/Virtual Attendants] Mobile Virtual Attendant behaviors now return their response on a new page. Previously the response was displayed below the submit button. The state of the response page is now cached so that the back button works properly. This allows responses to include links to new records, with the back button returning to the response without re-running the behavior. By not caching the behavior page, the mobile app can now instantly see any changes made to the behavior in Cerb. [Mobile/Workspaces] Mobile worklists can now be paged, sorted, filtered, and searched in place using Ajax. Previously, these actions were initiating a full page reload due to the way that popups work in jQuery Mobile. The reload was displaying a 'flash of unstyled content' on mobile devices. [Mobile/Virtual Attendants] Mobile Virtual Attendants can now return different types of responses. Previously, all messages had to be text-based. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return HTML responses. Any provided Javascript is evaluated, which makes interactive responses possible. For example, a Virtual Attendant can return a real-time chart using an HTML5 canvas. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return interactive worklists as responses. Previously, behavior variables that contained a list of records had to be displayed as text with links back to each record. Now any list variable on the behavior can be sent to a worker's mobile device. This displays a mobile worklist that's sortable, pageable, and filterable. The results also display properties about each record, and clicking on a record will display its mobile profile. The back button can be used to return to the worklist. For example, a mobile VA can send a list of tasks or tickets to a worker, and the worker can use that worklist in place as if they had searched for those results themselves. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return multiple responses to a single request. For example, a text response can state "Here are the results I found for you" and a second response can display the results as an interactive worklist. [Mobile/Performance] Implemented caching for the common navigation pages in the mobile interface: search, workspaces, workspace tabs, pages, and Virtual Attendants. The content in these pages rarely changes; they'll now be pulled from the server once per session. Closing and reopening the app, or switching to the app from another app, will clear the cache. This significantly reduces mobile bandwidth usage and improves perceived performance. [Mobile/Profiles/Plugins] Implemented a 'mobile.profile.block' extension point for plugins to provide custom content on profiles in the mobile interface. [Mobile/Profiles/Ticket] Ticket profiles in the mobile interface now display the most recent message on the ticket, and the conversation history can be paged forward and backward. [Mobile/Profiles/Ticket] Tickets can be replied to from the mobile interface. The reply button will automatically quote the currently displayed message, and the status and reopen date can be set. In order to reduce extra work from a mobile device when pruning quotes, only the most recent message worth of comments is displayed. In other words, quotes like ">>> Something said three messages ago" are automatically removed. When possible, signatures in quoted text are also automatically removed. [Mobile/Profiles/Ticket] Basic ticket properties can be edited from mobile profiles: status, reopen date, owner, and spam training. [Mobile/Profiles/Task] Basic task properties can be edited from mobile profiles: title, status, and due date. [Mobile/Profiles/Message] Message profiles in the mobile interface show the full email content. [Mobile/Calendars] Calendars are now displayed in a compact format in the mobile interface. These mobile calendars are displayed on workspace tabs, in workspace widgets, and on calendar profiles. Days that have events are indicated with a white circle. Clicking a day will select it, denoted by a pale blue circle, and its events will be listed below the calendar. Clicking an event from the list will display its profile, and the back button will return to the list with the previously selected date still highlighted. [Mobile/Calendars] In mobile calendars, the current day is now highlighted as a filled in circle compared to the outlined circles denoting days with events. [Mobile/Calendars] Mobile calendars can be paged forward and backward to adjacent months. A 'today' button is also provided to quickly reset the calendar on the current month with the current day selected. The selected month and year will be remembered per calendar for the duration of the session. [Mobile/Calendars] Mobile calendars now tag daily events as a block of 'available' or 'busy' time. [Mobile/Profiles/Virtual Attendants] Virtual Attendant custom behaviors are now available on mobile profiles. These are the same behaviors that show up in the desktop interface, enabling powerful automation from mobile devices. [Mobile/Bookmarks/Usability] The mobile interface now allows any page to be added to the menu as a bookmark. This provides one-click access to frequently used widgets, profiles, Virtual Attendant behaviors, etc. To add a bookmark, navigate to a page and then click the 'menu' button in the top right. In the bookmarks section there will be an 'add' button if the page isn't a bookmark yet, and a 'remove' button if it is. Bookmarks are stored locally on each device, so different devices can have different mobile bookmarks even when the same user is logged in. Bookmarks are currently organized alphabetically. [Mobile/Mail/Compose] Added a 'Compose' page to the mobile interface. This can send mail from any group the current worker is a member of. The 'To' field offers autocompletion for multiple email address recipients. An 'Insert signature' button will use the proper signature for the selected group and bucket. After sending the message, the worker will be redirected to the new ticket's profile. [Mobile/Profiles/Addresses] Basic email address properties can be edited from mobile profiles: first name, last name, is banned, is defunct, and organization. [Mobile/Profiles/Addresses] Mobile email address profiles provide a 'Search ticket history' button that lists all tickets where the address is a requester. [Mobile/Profiles/Addresses] Mobile email address profiles provide a 'Compose' button that switches to the compose page with the email address pre-filled. This provides a similar workflow to the full interface where an organization is selected in order to determine the appropriate contacts. [Mobile/Profiles/Orgs] Basic organization properties can be edited from mobile profiles: name, street, city, province, postal, country, phone, and website. [Mobile/Profiles/Orgs] Organization mobile profiles provide a 'Search contacts' button which lists all associated email addresses in a worklist. [Mobile/Profiles/Orgs] Organization mobile profiles provide a 'Search ticket history' button which lists all associated tickets in a worklist. [Mobile/Notifications] Clicking on a mobile notification will now display its profile instead of opening up a browser to the full site. This allows a notification to be researched without leaving the mobile interface. [Mobile/Notifications] Mobile notification profiles provide a 'Mark as read' button that clears the notification and returns to the previous page. This allows notifications to be saved for later if they're not currently actionable. [Mobile/Notifications] The unread notification count in the mobile interface now updates every time a new page is displayed. The count is still efficiently cached on the server. [Mobile/Profiles/Comments] Mobile profiles now display all the comments on a record. The most recent comment is displayed first, and buttons allow navigation forward and backward. [Mobile/Profiles/Comments] New comments can be created from mobile profiles, with the ability to notify specific workers. JIRA plugin [JIRA/Plugins] Added a 'JIRA Integration' plugin to the Plugin Library. This automatically synchronizes JIRA project and issue information. It also extends Virtual Attendants with the ability to remote control JIRA data. JIRA Projects and Issues can be accessed from Cerb's global Search menu. JIRA data can also be linked to other records (e.g. addresses, orgs) to track customer interest in issues and provide Virtual Attendants with data for following up on that interest. [JIRA/Virtual Attendants] Implemented an 'Execute an API request to JIRA' action in Virtual Attendants. Rather than being restricted to a few options, this can make any API calls to JIRA that the given credentials are authorized to do. For this reason, it is important to restrict this action to only trusted Virtual Attendants. Other VAs can still delegate actions to the behaviors on trusted VAs with access to JIRA. Check the online documentation for examples. [JIRA/Issues/VAs] Implemented Virtual Attendant custom behaviors for JIRA Issue records. For example, a 'Resolve' behavior could close a JIRA issue from Cerb. 6.5.1 [Virtual Attendants/Simulator/HTTP Requests] When a Virtual Attendant executes an HTTP request as an action, a new "Also execute HTTP request in simulator mode" option is available. This is useful for testing behaviors when an HTTP request is read-only (e.g. GET), and it's also useful for testing live PUT/POST requests without leaving the simulator. [Virtual Attendants/Simulator/Run Behavior] Virtual Attendants using the 'Run behavior' action may now enable an 'Also run behavior in simulator mode' option. Previously, the simulator only showed that a behavior would have run. Now delegate behaviors can also run in simulator mode, which makes it much easier to test and troubleshoot complex chained behavior. [Virtual Attendants/Scheduled Behavior/Usability] The scheduled behavior popup on profiles now provides enough room for the "When:" text box. Previously, if the drop down of date fields was very wide then the text box could be compressed to only a few characters. If the dropdown is exceptionally wide now, the text box will wrap to a new line. [Devblocks/Platform/Resources] TTF and WOFF font resources will now be transferred through the resource proxy with the proper mime types. [Virtual Attendants] In Virtual Attendant actions, the Virtual Attendant itself will now always appear as a target in the 'On:' parameter. This happened in some places (e.g. mobile behaviors, API behaviors) but not everywhere else. This makes it much easier to delegate behaviors between Virtual Attendants using the 'Custom virtual attendant behavior' event. [Virtual Attendants/Links] Virtual Attendants can use a new 'Get Links' action to load links of any type on any related record into a variable or placeholder. For example, when new mail is received a Virtual Attendant could check for a specific type of link (e.g. product, license) on the organization of the message sender. [CHD-3557] [Workspaces/Dashboards/Subtotals] Fixed a bug where filters with NULL (e.g. blank) values in worklist-based widgets were being ignored in some cases. For instance, a pie chart showing task assignments based on a worker custom field, with an 'assignee is not blank' filter, would show all workers including 'nobody'. [Setup/Branding/Usability] Renamed 'Logo & Title' to 'Branding' in the Setup->Configure menu. [Setup/Branding] The favicon used by Cerb is now configurable on the Setup->Configure->Branding page. Thanks to Niek Beernink @ Oxilion.nl for the contribution! [CHD-3464] [Consistency] Fixed a consistency issue where the refresh button on some profiles (e.g. task, worker) said "Reload this ticket" in the tooltip. This was due to the reuse of text from the translation system. These tooltips now show 'Refresh'. [CHD-3561] [Setup/Mail/Filters] Fixed an issue on the Setup->Mail->Filtering page where 'Create behavior' buttons weren't being displayed for each of the Virtual Attendants listed. [CHD-3565] [Virtual Attendants/Comments] The 'New comment on a record' event can now use the comment's parent record or author as 'On:' targets for actions. These were previously ignored because they are abstract (i.e. they can end up being various record types, and it's not possible for the simulator to know in advance). The author and parent record of a comment still can't be used in the 'On:' parameter of run behavior, schedule behavior, or unschedule behavior actions; instead, the desired record should be loaded into a private variable of a specific type (using {{comment_record_*}} placeholder fields), and that variable can be used as a target. [Comments/Worklists/Choosers] Implemented subtotals, filters, and choosers for comment worklists. [Worklists/Export] Fixed errors when exporting virtual fields from a worklist. [Virtual Attendants/Comments] When simulating new Virtual Attendant behaviors on the 'New comment on a record' event, a specify comment record can now be targeted for testing. Previously this wasn't possible due to a lack of comment choosers. [Support Center/Code Cleanup] Fixed a bug in the Support Center that ignored the sort order of the menu options. [CHD-3566] [Time Tracking/Code Cleanup] Fixed an error being displayed in the 'Time Spent' field on Time Tracking profiles. [Less]

Release notes for Cerb 6.5 Cerb (6.5) is a major functionality update released on September 20, 2013. It contains over 144 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.5 Core [CHD-3425] [Virtual ... [More] Attendants/Code Cleanup] Fixed a PHP error regarding "Undefined variable: func in abstract_view.php" when Virtual Attendant behaviors contained list variables with a specific combination of parameters. [Contacts/Snippets] Fixed an issue where the names of Contact Person records always displayed '(contact person)' in snippets and Virtual Attendant placeholders. [Virtual Attendants/Variables] Virtual Attendant behavior variables now support parameters based on each type of variable. This provides more control over how they operate, and it also makes new variable types possible (like a picklist of pre-defined options). [Virtual Attendants/Variables] Text-based Virtual Attendant behavior variables can be configured for single-line or multiple-line input. Previously, all text variables were single-line input, which made it difficult to enter certain kinds of data (e.g. long comments). [Virtual Attendants/Variables] Virtual Attendant behavior variables can be reordered by dragging them in the UI [Virtual Attendants/Variables] Virtual Attendant behaviors may specify picklist (drop down) variables. Picklists require a worker to pick an option from a list of predefined options. Previously, only freeform text entry was available. This is particularly useful for macro behaviors. [Snippets/Tester/Usability] The snippet tester now displays output with a fixed width font that preserves whitespace. Previously, tester output stripped whitespace. This made it impossible to check the style of indentation (e.g. at the beginning of paragraphs, or in fragments of code). [Virtual Attendant/Usability] The Virtual Attendant action for entering custom scripts no longer auto wraps the contents of the text box. This makes it easier to read source code. [Virtual Attendant/Simulator/Usability] Added an indent to the form elements in the Virtual Attendant Simulator to improve readability. [Virtual Attendants/Simulator/Variables] The public variables of Virtual Attendant behaviors may now be changed from within the simulator. This makes it much easier to test macros. [Comments/Snippets] Implemented two new placeholders for comment records. The record_watchers placeholder is a list of watchers on the record containing the comment. The record_watchers_emails placeholders contains a comma-delimited list of watcher email addresses. This was requested by several people who wanted a way to relay an email to all watchers about comments on records of any type using Virtual Attendants; however, it can also be used to display a list of watchers anywhere the comment is referenced. [Plugins/Choosers] Choosers can be opened in 'single selection' mode, where the first selection closes the chooser and returns control to the caller. This provides all the benefits of choosers for situations where a single record must be selected. [Virtual Attendants/Simulator/Usability] The output of the Virtual Attendant simulator no longer has a maximum height before introducing scrollbars. Having multiple scrollable sections made it more difficult to read the output or to scroll down the page. [Virtual Attendants/Simulator] When using the Virtual Attendant simulator, it is now possible to choose the exact record that the current behavior is being tested against. Previously, the simulator would choose random records to help test behaviors, but this often required opening up the simulator many times in order to find a suitable record. For macros, it was possible to run the simulator from a record profile in order to test using that record, but this option wasn't available to events like 'New message on a group conversation'. [Virtual Attendants/Simulator/Usability] In the Virtual Attendant simulator, data entry for parameters and values have been moved to tabs. When a behavior provides parameters (public variables for entry by a worker), the parameters section is shown by default and the long list of values is hidden on a second tab, which improves usability by reducing clutter. [Virtual Attendants/Snippets] Implemented a new json_decode() function for snippets and placeholders to convert a JSON string to an associative array. This can be used to easily reference JSON results from API calls within Virtual Attendant behaviors (or snippets in special situations). [Virtual Attendants/Snippets] Implemented a new json_pretty filter for snippets and placeholders to optimize the human readability of a JSON string. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Virtual Attendants] Virtual Attendants are now first-class records (like groups and workers), with worklists, profiles, peek, ownership rights, etc. Previously, Virtual Attendant behaviors were owned directly by roles, groups, and workers; but this was creating clutter and confusion because some behaviors are related but there was no indication of this in the UI. Now, multiple Virtual Attendants can be created to contain any number of behaviors, and each VA can be owned by a worker, group, or role. All existing behaviors have been migrated to a new default Virtual Attendant record for each distinct owner. Virtual Attendants now show up in the global 'Search' menu, and clicking into a VA profile is where you will find the behavior trees and scheduled behavior. This also provides many new possibilities for future expansion; for example, Virtual Attendants can log errors to their profile in an easy-to-find tab. You can export and import behaviors between Virtual Attendants to place related behaviors together. [Messages/Performance/Snippets] The placeholder for message content is now lazy-loaded only when it is needed. This reduces extraneous queries from hitting the database when Virtual Attendants or snippets use message fields but ignore content. [Virtual Attendants/Macros/Profiles] The 'Virtual Attendants' button on profiles now organizes behaviors by Virtual Attendant. This makes it much easier to find the behavior you're looking for. Additionally, the macro menu no longer displays two lines for each entry; instead, behaviors are indented below their Virtual Attendant. This allows more options to be displayed in a smaller space, and it's less visually confusing. [Virtual Attendants/Activity Log] Activity Log entries that are created in response to Virtual Attendant actions will now log each Virtual Attendant as the actor. Previously, these entries were created as if the behavior's owner (e.g. worker, group) had performed them, which could lead to some confusion of accountability. Since Virtual Attendants are now first-class objects, they can be held accountable individually for actions they take. The Activity Log will also specify the name of the responsible behavior next to the Virtual Attendant. [Debug/Virtual Attendants] The /debug/export_attendants page will now export all behaviors grouped by Virtual Attendant. [Virtual Attendants/Scheduled Behavior] The 'Scheduled Behavior' tabs have moved to Virtual Attendant profiles. Previously, scheduled behavior was shown on worker and group profiles, since those records directly owned behaviors. The records targeted by scheduled behavior still show a summary at the top of their profile. [Mail/Reply/Virtual Attendants/Macros] The 'Virtual Attendants' button that is displayed when replying to a message will now display macros grouped by Virtual Attendant. [Setup/Virtual Attendants] The 'Setup->Configure->Virtual Attendants' page now displays a worklist of Virtual Attendants with links to profiles. Previously, a funky interface was used that required an admin to pick an owner from a list to view their owned behaviors in a tab. The new process is consistent with the way the rest of Cerb works. [Virtual Attendants/Snippets] Implemented a new jsonpath_set() function for snippets and placeholders to dynamically create deeply nested JSON objects from inside scripts. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Setup/Mail/Filtering/VAs] The Setup->Mail->Filtering page now shows the mail filtering behavior from all global Virtual Attendants on a single page. Previously, it was only possible to have a single global Virtual Attendant and its use was implied on this page. [Setup/Mail/Filtering/VAs] When an admin views the Setup->Mail->Filtering page for the first time, Cerb will offer to create the first global Virtual Attendant if one doesn't exist already. This improves the onboarding experience. [Virtual Attendants] Virtual Attendants may now be disabled, which treats all of their behaviors as being disabled. These behaviors will not trigger during events, and will now show up as macros on profiles. This makes it very simple to simultaneously deactivate related behaviors, which was tedious in earlier versions. Additionally, a worker can disable a Virtual Attendant while building and testing its behaviors. [Activity Log] Activity Logs for actor profiles (address, worker, group, virtual attendant) now display entries where the record was either an actor or a target of the activity. Previously, the log only showed actor activity for those records, and target activity for everything else. This meant that when viewing an address's activity from its profile, you wouldn't see log entries for when that address replied to conversations (as an actor), only when workers performed actions on that address (as a target). This change provides a more comprehensive view of the activities a record was involved with. [Activity Log/Groups] Group profiles now display an Activity Log tab. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can own custom fieldsets, providing them with long-term storage for arbitrary data on any record. This enables some very interesting new automation workflows. For instance, a monitoring Virtual Attendant can remember the last time it notified each worker about something by using a custom fieldset with a date on worker records. Similarly, a sales Virtual Attendant can keep track of its progress through an automated sales process with a custom fieldset that it saves on opportunities. [Virtual Attendants/Macros] Application-owned Virtual Attendants can now create custom behaviors for any record type. This allows global macros that are accessible by all workers, which greatly simplifies many workflows. Previously, these macros could only be created by VAs owned by groups, roles, or workers. [Virtual Attendants/Macros] Implemented a 'Custom virtual attendant behavior' event. This is the ideal place to implement generic behaviors that don't rely on a specific record type. For example, a Twitter Bot could schedule a recurring behavior to look for new @mentions, and it wouldn't make sense to target this behavior to any particular record. Previously, we had recommended to bind these generic behaviors on worker records just because it made them easy to manage from a profile. Now we recommend that these behaviors be migrated to Virtual Attendant profiles. [CHD-3113] [Support Center/Logins/Usability] When a Support Center page requires a login, a visitor will be redirected to their original destination after successfully logging in. Previously, the Support Center didn't even provide a login form to anonymous visitors if they requested a protected resource, it just displayed the default page. The new process should make it much easier to send contacts direct links to a specific ticket history, or protected knowledgebase articles. [Support Center/Usability] By default, the logo image on the Support Center is now a shortcut link back to the default page. [CHD-3441] [Support Center] When a customer views a ticket in the Support Center, there is now a reply button per message and no reply from is shown by default. Previously, a single reply form was always displayed at the top of the ticket which led to much confusion. [CHD-3148] [Support Center] When a customer replies to a ticket in the Support Center, the original message will now be automatically quoted in the response. [Platform/Popups/Usability] Popups are now limited to a height no more than 85% of the current browser height. Previously, popups could be so tall that they scrolled off the page. This made them difficult to work with; particularly when dragging them around. [Virtual Attendants/Macros/Plugins/Platform] Any Virtual Attendant behaviors that respond an event trigger will now be returned along with a snapshot of their data at their conclusion. This allows the caller to retrieve detailed information from those responders, and in an arbitrary way. [Virtual Attendants/Actions/Run Behavior] Virtual Attendant behaviors may now use a global '(Run behavior)' action. This is similar to 'Schedule behavior', except it runs the behavior immediately and allows the caller to retrieve values from the delegate behavior. For example, if one Virtual Attendant delegates another VA's behavior in order to create a task, then the caller can afterwards retrieve information about the created task from the delegate. This greatly improves the reusability of Virtual Attendants, as specialized VAs can handle routine actions, and helper VAs can delegate requests to them. This also makes it possible to build mediator VAs that listen on channels like SMS, IM, and Campfire; with requests being delegated to VAs that can do almost anything possible in Cerb: send reminders; create and complete tasks; check and change calendars; interact with Twitter, Facebook, JIRA; etc. [Virtual Attendants/Scheduled Behavior] Fixed an issue with the 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants. Disabled behaviors were not included in the list of available options, so if the actions referred to a behavior while it was disabled, and that action was edited and saved, then it would no longer refer to the behavior afterwards. Disabled behaviors are now displayed in the action, but they're marked as being disabled in case this is unintentional. [Virtual Attendants/Actions] When a Virtual Attendant action is missing, the behavior editor will now provide more helpful information, including an indication of what it was supposed to be. Previously, a blank action box was shown without providing any clue about what was missing. [Support Center/History/Reply] Fixed warnings created by the Support Center when a customer replies to a ticket without any attachments. [Virtual Attendants/Actions/Variables/Usability] In Virtual Attendants, the actions for setting variables are now displayed at the top of the available actions. As with other global actions, they are surrounded by parentheses. Previously these were sorted alphabetically with other 'Set' options, which made them more difficult to find. [CHD-1050] [Worklists/Custom Fields] When displaying a multiple value custom field as a worklist column, all of the selected values will now be displayed. Previously, only a single value per custom field was displayed based on what matched the search filters. [CHD-1086] [Custom Fields/Attachments] Implemented two new custom field types: file and multiple files. These types allow arbitrary attachments to be attached to records through custom fields. Internally, these fields use the attachments system and they store file IDs. [Virtual Attendants/Scheduled Behavior] The 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants are now global. They are available in all events and plugin-provided events do not need to implement them. Additionally, the action names are wrapped in parentheses so they appear at the top of the list of available actions. [Custom Fieldsets] Custom fieldsets may now be owned by the application. These fieldsets are readable by all workers but only configurable by admins. [Virtual Attendants/Custom Script] The 'custom script' condition in Virtual Attendant outcomes now a placeholders menu and script tester. [Calendars/Virtual Attendants] Calendar records can now also be owned by Virtual Attendants or the Application. [CHD-3460] [Virtual Attendants/Calendars] All Virtual Attendant behaviors may now use 'calendar availability' as a condition in outcomes. For example, this can be used to send different auto-replies based on availability. [CHD-2866] [Virtual Attendants] The 'new message on a watched conversation' event will now always include a ticket's owner even if they aren't a watcher. [Setup/Localization] A Setup->Configure->Localization page has been added for selecting the default date/time format for everywhere dates are displayed. Admins can choose between 12hr or 24hr formats, and this selection will cover all workers that don't have an established preference. [CHD-3064] [CHD-2973] [Preferences/Localization] Each worker can choose their desired time format (12-hour or 24-hour) from the 'Settings' page in their worker menu. [Virtual Attendant/Events] Added a new application-level 'Before sending worker message' event. Previously this was only possible at the group level. [Virtual Attendant/Events] Added a new application-level 'After sending worker message' event. Previously this was only possible at the group level. [CHD-3340] [Virtual Attendants/Mail] Virtual Attendant behaviors on the 'Before sending worker message' event may now add custom mail headers to the outgoing message. This was requested as a way to force read receipts, among other workflows. [Virtual Attendants/Behaviors] Virtual Attendant macro behavior may now be marked as public or private. A public behavior is visible to everyone with access to the VA (on profiles, etc). A private behavior is only visible to the VA itself. Private behaviors are useful for implementing helper macros within a VA that shouldn't be exposed to the outside world. These are generally used from 'Run behavior' or 'Schedule behavior' actions. [Virtual Attendants/Permissions/Events] Admins can choose which events each Virtual Attendant is capable of creating behaviors for. The options are 'allow all', 'allow these:', and 'deny these:'. This provides a way to offer limited Virtual Attendant functionality to workers with all use cases requiring prior approval. After the upgrade, all existing Virtual Attendants will default to 'allow all' events. [Virtual Attendants/Permissions/Actions] Admins can choose which plugin-provided actions a Virtual Attendant is capable of using in behaviors. The options are 'allow all', 'allow these:', and 'deny these:'. For example, the actions for JIRA and Twilio may be restricted to admin-controlled global VAs that worker VAs can delegate to. Actions that directly communicate with external apps and services can be restricted from use by most workers. After the upgrade, all existing Virtual Attendants will default to 'allow all' actions. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can specify a format for its output of either 'text' or 'JSON'. JSON output will be automatically be converted to an object when it is saved to a placeholder. This is particularly useful to simulate JSON responses from actions that perform API calls. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can be configured to only set the placeholder when in simulator mode. This assists with providing test data in the simulator without affecting the outcome of a behavior when it runs normally. [Virtual Attendant/Simulator] Public worklist variables in Virtual Attendant behaviors can now be tested properly in the simulator. [Virtual Attendants/Actions] The 'Schedule behavior' and 'Run behavior' actions in Virtual Attendants can now include placeholders in the parameters being passed to the other behavior. [Virtual Attendants/API] Implemented '/rest/va/list.json' in the Web API for retrieving the list of Virtual Attendants that are visible to the current worker. This can include an 'expand' parameter with the option 'behaviors' to list all of the defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/123.json' in the Web API for retrieving the a particular Virtual Attendant. This can include an 'expand' parameter with the option 'behaviors' to list all of its defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/behavior/123/run.json' in the Web API for running a 'Custom API request' Virtual Attendant behavior. This provides a standardized way for external applications and services to communicate with Virtual Attendants in Cerb. For example, a Campfire Bot can listen for messages in a chat room and relay a specific pattern (e.g. "@Cerb do something") to a specific VA behavior through the Cerb API. The response is a dictionary of all the behavior's values after running, including public and private variables. If a behavior retrieves a list of tickets, then their details will be available in the response for use outside of Cerb. [Virtual Attendants/API] Added a new 'Custom API request' event to Virtual Attendants. This can be utilized by app-owned and worker-owned VAs. These behaviors work similarly to macros, except they are only triggered through the API from external apps and services. This allows for interaction with Virtual Attendants through mobile text messages, email, instant messages, Campfire/Hipchat, mobile applications, browser plugins, etc. Custom API request behaviors always target the owning Virtual Attendant, and they provide an 'Add to API response message' action that appends text to the _response value of the API response. Using the _response value is optional, but it provides for generalized interaction with Virtual Attendants through the API. For example, an iOS app could display a list of all Virtual Attendants and their API-enabled behaviors. Running any behavior could prompt for its public parameters, and the response message could be displayed. It's also possible to use the 'custom placeholder' action for additional outputs. [Virtual Attendants/API] When a Virtual Attendants dictionary is converted to an array (e.g. for use by the Web API), any nested dictionaries will also be converted to arrays. Previously, if a behavior contained extra dictionaries (e.g. a list of records from a worklist search), it would return the IDs of those records but not their values. [Virtual Attendants/Simulator] When simulating the Virtual Attendant 'Run behavior' and 'Schedule behavior' actions, the simulator output will now show behavior variables being set. [Virtual Attendants/Simulator] Implemented Virtual Attendant simulator output for the 'Send email to notified worker' action in 'New notification for me' behaviors. [Setup/Mail/Parser] Raw email messages can be imported from Setup->Mail by pasting them into a textbox. This simplifies development, training, and evaluations. Previously, these messages had to be saved in the /storage/mail/new/ directory and then the parser scheduler job had to be manually run. [CHD-957] [CHD-3037] [CHD-3173] [Setup/Mail/Parser] Incoming mail messages that failed to parse can now be viewed, retried, or deleted from the Setup->Mail->Failed Messages page. Previously, administrators had to proactively monitor these files on the disk in the /storage/mail/fail/ directory, occasionally move them to /storage/mail/new/, and run the parser scheduled job manually in order to inspect the output. Failed mail is now displayed in a familiar worklist format with a peek popup to view each message source. [Web-API/Usability] Added a QR code image to the Web API Credentials peek popup. This allows mobile apps to quickly scan the QR code to copy the access and secret keys rather than requiring a user to laboriously type them. [Contexts/Messages] The generic label for Message records now shows the sender email, ticket mask, and ticket subject. Previously this just showed an unhelpful '(message)' placeholder. The label is used in Virtual Attendants, the Web-API, and the mobile app. [Contexts/Activity Log] Activity Log contexts now provide actor_* and target_* placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Activity Log] Activity Log contexts now provide a human-readable 'event' placeholder to describe the activity being logged. This can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Workers] Worker contexts now provide is_disabled and is_superuser placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Snippets/VAs/Workers] Added 'last activity date' to worker placeholders. [Devblocks/Workspaces/Charts/Plugin Development] The Devblocks HTML5 charting library now mediates all mouse interaction with the charts. Listeners can bind to 'devblocks-chart-click' or 'devblocks-chart-mouseover' to receive updates about user input. The returned event includes information about the closest data point to the mouse cursor, including chart coordinates. This saves the caller a lot of work when designing interactive charting elements. [Workspaces/Dashboards/Line Charts] Line chart dashboard widgets now display a horizontal line through the selected data point to make lateral comparisons easier. [Workspaces/Dashboards/Scatterplots] Scatterplot dashboard widgets now display crosshairs that intersect at the selected data point. This makes comparisons easier in both dimensions by creating quadrants. [Workspaces/Dashboards/Gauges] Gauge dashboard widgets now display their labels below the widget for uniformity. [Virtual Attendants/Variables/Lists] When a Virtual Attendant behavior has a list variable, the resulting worklist view_id will now be saved in the dictionary in the format var_name_view_id. This allows reuse of the underlying worklist for all kinds of functionality. Notably, it's currently used to send worklists to the mobile app. It could also overcome the 100 object limit of list variables now. [Calendars] Fixed an issue where long-running calendar events that started before and ended after the current month wouldn't be displayed as spanning the entire month. [Platform/Contexts/Plugins] Added a getPropertyLabels($dictionary) method to Extension_DevblocksContext extensions. This provides more terse human-readable text for labels when dictionaries are used on worklists and profiles (particularly in the mobile interface where spaces is limited). For example, "Ticket initial message sender address" can be abbreviated to "First wrote". [Mail/Display] Fixed an issue when displaying tickets where very long messages (i.e. over 1MB) could cause a PHP timeout before the page was displayed. This was caused by attempting to auto-hyperlink URLs found within the email message, and it was exacerbated if 'read all' mode was always enabled when reading tickets. Cerb will no longer attempt to auto-hyperlink URLs within messages that are greater than 512KB in length. [Platform/Plugins/Search] Devblocks now provides an OPER_CUSTOM operator for DevblocksSearchCriteria objects. This allows the caller to provide their own WHERE clause. For example, in some situations a query needs to modify a value before doing a comparison on it (e.g. fieldvalue+5 > otherfield_value). [Devblocks/Placeholders/Usability] The 'devblocks_prettytime' modifier in placeholders now outputs 'just now' instead of '0 secs'. [Calendars/Datasources/Performance] On calendars, worklist datasources were previously inconsistent in that the 'end date' could use placeholders while the 'start date' required a specific date field. This option was provided so that events could be arbitrary lengths; however, it wasn't possible to efficiently determine the events that needed to be displayed for a given month because the placeholders would have to be evaluated for every record in the database. In order to fix this issue, the 'end date' for worklist datasources on calendars now requires an explicit date field. Event durations can be set by using the new 'offset' fields for the start and end dates. For example, an event can end using the same field as the start date, but with a "+2 hours" offset. These offsets are much more efficient to process algorithmically in the database than open-ended placeholders. [CHD-3515] [Calendars/Datasources] Fixed an issue with displaying worklist records on calendars when the events didn't start and end within the same calendar month. For example, if an event started on August 31 2013 and ran for 3 days, it wasn't being displayed on the September calendar. [Virtual Attendants/Actions/HTTP Requests] A new 'Execute an HTTP request' action in Virtual Attendants allows them to send and receive data with other apps and services. The results of an HTTP request are stored in a custom placeholder that can be used by subsequent outcomes and actions. JSON responses are automatically converted to an object. Image resources as a response (e.g. PNG, GIF, JPEG) are converted to base64 text. For example, when new mail is received a Virtual Attendant could send relevant details to an external URL (like a webhook). A behavior could also request information from any source as a URL; e.g. datacenter temperature, website traffic, monitoring metrics, etc. Mobile plugin [CHD-1056] [CHD-1108] [CHD-2378] [Mobile/Plugins] A 'Mobile Interface' plugin has been added to the Plugin Library. We had originally held off on creating a mobile interface because most workers use desktop computers and Cerb's UI workflow design is heavily dependent on multiple layers of popups to enable multiple actions from the same page. With the introduction of custom workspace pages in 6.0 and distinct Virtual Attendants in 6.5, the components of a mobile interface clicked into place. Rather than seeking to replace all the functionality in Cerb's normal UI, the mobile UI provides a access to previously curated content. The primary focus is on providing access to notifications, workspaces, and special Virtual Attendant mobile behaviors. The mobile plugin is built using jQuery Mobile, so there is a large list of supported devices: iPhone, iPad, Android, Windows Phone, Blackberry, WebOS, etc. We feel that a slim web interface is an ideal mobile strategy for Cerb because the functionality is contained within a plugin that is always in sync with the version of the main project. With mobile apps in various app stores using Cerb's API, users would constantly run into issues with version incompatibilities. Once logged in, the mobile interface can be accessed from any mobile browser by visiting the '/w' page at your normal Cerb URL. This can be bookmarked or saved to your device's home screen. [Mobile] Notifications can be viewed in the mobile interface. At the moment they open up a new browser tab to the full Cerb UI. In the near future we plan to implement mobile-friendly profiles for all record types. A count of unread notifications is displayed on a badge at the bottom of the app. [CHD-891] [Mobile/Workspaces] Workspaces can be viewed in the mobile interface. All workspaces that the current worker has access to will be displayed. The worker is prompted in several steps to select a workspace, a tab, and finally a worklist or a widget. The pages for tabs, worklists, and widgets provide shortcuts to jump back to the previous selections (for instance, from a widget to a page or tab). A filter box above the list narrows down the choices (for example, only showing pages with a specific owner). At the moment, clicking on a worklist row opens up the record in the full Cerb UI in the default browser. [Mobile/Virtual Attendants] Added a new 'Mobile behavior' event to Virtual Attendants. These behaviors can be run from mobile devices for any kind of workflow. For instance, mobile behaviors can create or search tickets, create tasks or notifications, search external systems for information, etc. Any public behavior variables will prompt the current worker for additional information. These behaviors can also be implemented on app-owned VAs so they are available to all workers by default. Mobile behaviors can respond with various types of messages that are displayed in a mobile device (e.g. text, html, maps, etc). [Mobile/Virtual Attendants] Virtual Attendants with mobile behaviors can be viewed in the mobile interface. All VAs that the current worker has access to will be displayed. When a Virtual Attendant is selected, a list of its available mobile behaviors is displayed. Selecting a behavior will prompt for the input of any public behavior variables (for instance, a mobile behavior to create a task would prompt for the task's name and due date). The response from the Virtual Attendant is displayed in a message reminiscent of a chat bubble. This functionality is incredibly powerful; Virtual Attendant powered mobile behaviors can provide workers with shortcuts to accomplish almost any workflow. Those behaviors are built inside Cerb's normal web interface. [Mobile/Plugin/iOS] The Cerb mobile interface now supports being added to the iOS home screen as a web app. This removes the location bar and footer from Mobile Safari so the experience feels more like a native app. Device-specific icons and start screens are provided (e.g. iPhone, iPad, retina). [Mobile] Implemented a sidebar panel in the mobile interface. This provides access to more functionality than can fit in the footer shortcuts: favorites, compose, pages, search, etc. [Mobile/Workspaces/Pages] The mobile interface now provides access to both workspaces and pages. The distinction is that a workspace is a page added by a worker to their navigation menu. Pages represent everything that a worker could choose to add to their menu as a workspace. [Mobile/Workspaces] The Workspaces shortcut in the mobile footer now displays a worker's workspaces in the same order that they appear in the full site. Previously this was displaying a list of all pages in alphabetical order. [Mobile/Profiles] The mobile interface now provides a profile page for every record type in Cerb. This makes it possible to gather more information without leaving the mobile site. Profiles also provide automatic links between related records. For example, from a ticket profile you can quickly view the sender's profile, their org's profile, the assigned group's profile, the ticket owner's profile, etc. [Mobile/Search] The mobile interface now provides a 'Search' page in the menu panel. This displays a list of every record type in Cerb. When a record type is selected then a mobile worklist is displayed with the matching records. Clicking on a record displays its mobile profile. The profile also contains a link to open the record in the full site. This improvement makes the mobile interface very useful for workers who need to perform quick record lookups while away from their desk. [Mobile/Workspaces] Mobile worklists now display their current filters above the list. Clicking a filter removes it. [Mobile/Workspaces] New filters can be added to mobile worklists using quick search functionality. Clicking the filters button above the list opens a popup that displays all searchable fields. [Mobile/Workspaces] Mobile worklists can use existing filter presets. After clicking on the filters button, all presets are displayed as buttons in a popup. Clicking one of these buttons will instantly replace the filters. This is particularly useful in a mobile environment, especially when performing ad-hoc searches rather than using prebuilt workspaces. [Mobile/Workspaces] Mobile worklists can be sorted in ascending or descending order on any available column. The field currently being sorted by is displayed above the list, and the arrow next to the label indicates the sort direction (i.e. asc, desc). [Mobile/Workspaces] Mobile worklists can be paged forward and backward. On subsequent pages, an option is provided to instantly jump back to the first page. In a slight deviation from the full UI, paging displays the current and total pages along with the total number of results. In the full UI, paging displays the current position in the results and the total number of results (i.e. no indication is given for the total number of pages). [Mobile/Workspaces] Mobile worklists can now display any number of fields for each row. Since screen space is generally limited on mobile devices, these fields are not displayed as horizontal columns like in the full UI, but as smaller vertical rows beneath each result's heading. At the moment, the displayed fields are based on useful defaults for each record type. In the near future this feature will support the ability to decide which fields should be displayed per worklist or worklist type. This functionality is actually more advanced than the main UI, since it uses the placeholders from Virtual Attendants and snippets instead of being confined by the results from the database. In the main UI, only a limited amount of information from related records is available as columns (e.g. ticket -> organization). With the placeholder approach, even content at the end of a long chain of related records can be displayed (e.g. ticket -> first message -> sender -> org -> custom field). [Mobile/Virtual Attendants] Mobile Virtual Attendant behaviors now return their response on a new page. Previously the response was displayed below the submit button. The state of the response page is now cached so that the back button works properly. This allows responses to include links to new records, with the back button returning to the response without re-running the behavior. By not caching the behavior page, the mobile app can now instantly see any changes made to the behavior in Cerb. [Mobile/Workspaces] Mobile worklists can now be paged, sorted, filtered, and searched in place using Ajax. Previously, these actions were initiating a full page reload due to the way that popups work in jQuery Mobile. The reload was displaying a 'flash of unstyled content' on mobile devices. [Mobile/Virtual Attendants] Mobile Virtual Attendants can now return different types of responses. Previously, all messages had to be text-based. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return HTML responses. Any provided Javascript is evaluated, which makes interactive responses possible. For example, a Virtual Attendant can return a real-time chart using an HTML5 canvas. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return interactive worklists as responses. Previously, behavior variables that contained a list of records had to be displayed as text with links back to each record. Now any list variable on the behavior can be sent to a worker's mobile device. This displays a mobile worklist that's sortable, pageable, and filterable. The results also display properties about each record, and clicking on a record will display its mobile profile. The back button can be used to return to the worklist. For example, a mobile VA can send a list of tasks or tickets to a worker, and the worker can use that worklist in place as if they had searched for those results themselves. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return multiple responses to a single request. For example, a text response can state "Here are the results I found for you" and a second response can display the results as an interactive worklist. [Mobile/Performance] Implemented caching for the common navigation pages in the mobile interface: search, workspaces, workspace tabs, pages, and Virtual Attendants. The content in these pages rarely changes; they'll now be pulled from the server once per session. Closing and reopening the app, or switching to the app from another app, will clear the cache. This significantly reduces mobile bandwidth usage and improves perceived performance. [Mobile/Profiles/Plugins] Implemented a 'mobile.profile.block' extension point for plugins to provide custom content on profiles in the mobile interface. [Mobile/Profiles/Ticket] Ticket profiles in the mobile interface now display the most recent message on the ticket, and the conversation history can be paged forward and backward. [Mobile/Profiles/Ticket] Tickets can be replied to from the mobile interface. The reply button will automatically quote the currently displayed message, and the status and reopen date can be set. In order to reduce extra work from a mobile device when pruning quotes, only the most recent message worth of comments is displayed. In other words, quotes like ">>> Something said three messages ago" are automatically removed. When possible, signatures in quoted text are also automatically removed. [Mobile/Profiles/Ticket] Basic ticket properties can be edited from mobile profiles: status, reopen date, owner, and spam training. [Mobile/Profiles/Task] Basic task properties can be edited from mobile profiles: title, status, and due date. [Mobile/Profiles/Message] Message profiles in the mobile interface show the full email content. [Mobile/Calendars] Calendars are now displayed in a compact format in the mobile interface. These mobile calendars are displayed on workspace tabs, in workspace widgets, and on calendar profiles. Days that have events are indicated with a white circle. Clicking a day will select it, denoted by a pale blue circle, and its events will be listed below the calendar. Clicking an event from the list will display its profile, and the back button will return to the list with the previously selected date still highlighted. [Mobile/Calendars] In mobile calendars, the current day is now highlighted as a filled in circle compared to the outlined circles denoting days with events. [Mobile/Calendars] Mobile calendars can be paged forward and backward to adjacent months. A 'today' button is also provided to quickly reset the calendar on the current month with the current day selected. The selected month and year will be remembered per calendar for the duration of the session. [Mobile/Calendars] Mobile calendars now tag daily events as a block of 'available' or 'busy' time. [Mobile/Profiles/Virtual Attendants] Virtual Attendant custom behaviors are now available on mobile profiles. These are the same behaviors that show up in the desktop interface, enabling powerful automation from mobile devices. [Mobile/Bookmarks/Usability] The mobile interface now allows any page to be added to the menu as a bookmark. This provides one-click access to frequently used widgets, profiles, Virtual Attendant behaviors, etc. To add a bookmark, navigate to a page and then click the 'menu' button in the top right. In the bookmarks section there will be an 'add' button if the page isn't a bookmark yet, and a 'remove' button if it is. Bookmarks are stored locally on each device, so different devices can have different mobile bookmarks even when the same user is logged in. Bookmarks are currently organized alphabetically. [Mobile/Mail/Compose] Added a 'Compose' page to the mobile interface. This can send mail from any group the current worker is a member of. The 'To' field offers autocompletion for multiple email address recipients. An 'Insert signature' button will use the proper signature for the selected group and bucket. After sending the message, the worker will be redirected to the new ticket's profile. [Mobile/Profiles/Addresses] Basic email address properties can be edited from mobile profiles: first name, last name, is banned, is defunct, and organization. [Mobile/Profiles/Addresses] Mobile email address profiles provide a 'Search ticket history' button that lists all tickets where the address is a requester. [Mobile/Profiles/Addresses] Mobile email address profiles provide a 'Compose' button that switches to the compose page with the email address pre-filled. This provides a similar workflow to the full interface where an organization is selected in order to determine the appropriate contacts. [Mobile/Profiles/Orgs] Basic organization properties can be edited from mobile profiles: name, street, city, province, postal, country, phone, and website. [Mobile/Profiles/Orgs] Organization mobile profiles provide a 'Search contacts' button which lists all associated email addresses in a worklist. [Mobile/Profiles/Orgs] Organization mobile profiles provide a 'Search ticket history' button which lists all associated tickets in a worklist. [Mobile/Notifications] Clicking on a mobile notification will now display its profile instead of opening up a browser to the full site. This allows a notification to be researched without leaving the mobile interface. [Mobile/Notifications] Mobile notification profiles provide a 'Mark as read' button that clears the notification and returns to the previous page. This allows notifications to be saved for later if they're not currently actionable. [Mobile/Notifications] The unread notification count in the mobile interface now updates every time a new page is displayed. The count is still efficiently cached on the server. [Mobile/Profiles/Comments] Mobile profiles now display all the comments on a record. The most recent comment is displayed first, and buttons allow navigation forward and backward. [Mobile/Profiles/Comments] New comments can be created from mobile profiles, with the ability to notify specific workers. JIRA plugin [JIRA/Plugins] Added a 'JIRA Integration' plugin to the Plugin Library. This automatically synchronizes JIRA project and issue information. It also extends Virtual Attendants with the ability to remote control JIRA data. JIRA Projects and Issues can be accessed from Cerb's global Search menu. JIRA data can also be linked to other records (e.g. addresses, orgs) to track customer interest in issues and provide Virtual Attendants with data for following up on that interest. [JIRA/Virtual Attendants] Implemented an 'Execute an API request to JIRA' action in Virtual Attendants. Rather than being restricted to a few options, this can make any API calls to JIRA that the given credentials are authorized to do. For this reason, it is important to restrict this action to only trusted Virtual Attendants. Other VAs can still delegate actions to the behaviors on trusted VAs with access to JIRA. Check the online documentation for examples. [JIRA/Issues/VAs] Implemented Virtual Attendant custom behaviors for JIRA Issue records. For example, a 'Resolve' behavior could close a JIRA issue from Cerb. [Less]

Release notes for Cerb 6.5 Cerb (6.5) is a major functionality update in development as of September 11, 2013. It currently contains over 112 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.5 Core ... [More] [CHD-3425] [Virtual Attendants/Code Cleanup] Fixed a PHP error regarding "Undefined variable: func in abstract_view.php" when Virtual Attendant behaviors contained list variables with a specific combination of parameters. [Contacts/Snippets] Fixed an issue where the names of Contact Person records always displayed '(contact person)' in snippets and Virtual Attendant placeholders. [Virtual Attendants/Variables] Virtual Attendant behavior variables now support parameters based on each type of variable. This provides more control over how they operate, and it also makes new variable types possible (like a picklist of pre-defined options). [Virtual Attendants/Variables] Text-based Virtual Attendant behavior variables can be configured for single-line or multiple-line input. Previously, all text variables were single-line input, which made it difficult to enter certain kinds of data (e.g. long comments). [Virtual Attendants/Variables] Virtual Attendant behavior variables can be reordered by dragging them in the UI [Virtual Attendants/Variables] Virtual Attendant behaviors may specify picklist (drop down) variables. Picklists require a worker to pick an option from a list of predefined options. Previously, only freeform text entry was available. This is particularly useful for macro behaviors. [Snippets/Tester/Usability] The snippet tester now displays output with a fixed width font that preserves whitespace. Previously, tester output stripped whitespace. This made it impossible to check the style of indentation (e.g. at the beginning of paragraphs, or in fragments of code). [Virtual Attendant/Usability] The Virtual Attendant action for entering custom scripts no longer auto wraps the contents of the text box. This makes it easier to read source code. [Virtual Attendant/Simulator/Usability] Added an indent to the form elements in the Virtual Attendant Simulator to improve readability. [Virtual Attendants/Simulator/Variables] The public variables of Virtual Attendant behaviors may now be changed from within the simulator. This makes it much easier to test macros. [Comments/Snippets] Implemented two new placeholders for comment records. The record_watchers placeholder is a list of watchers on the record containing the comment. The record_watchers_emails placeholders contains a comma-delimited list of watcher email addresses. This was requested by several people who wanted a way to relay an email to all watchers about comments on records of any type using Virtual Attendants; however, it can also be used to display a list of watchers anywhere the comment is referenced. [Plugins/Choosers] Choosers can be opened in 'single selection' mode, where the first selection closes the chooser and returns control to the caller. This provides all the benefits of choosers for situations where a single record must be selected. [Virtual Attendants/Simulator/Usability] The output of the Virtual Attendant simulator no longer has a maximum height before introducing scrollbars. Having multiple scrollable sections made it more difficult to read the output or to scroll down the page. [Virtual Attendants/Simulator] When using the Virtual Attendant simulator, it is now possible to choose the exact record that the current behavior is being tested against. Previously, the simulator would choose random records to help test behaviors, but this often required opening up the simulator many times in order to find a suitable record. For macros, it was possible to run the simulator from a record profile in order to test using that record, but this option wasn't available to events like 'New message on a group conversation'. [Virtual Attendants/Simulator/Usability] In the Virtual Attendant simulator, data entry for parameters and values have been moved to tabs. When a behavior provides parameters (public variables for entry by a worker), the parameters section is shown by default and the long list of values is hidden on a second tab, which improves usability by reducing clutter. [Virtual Attendants/Snippets] Implemented a new json_decode() function for snippets and placeholders to convert a JSON string to an associative array. This can be used to easily reference JSON results from API calls within Virtual Attendant behaviors (or snippets in special situations). [Virtual Attendants/Snippets] Implemented a new json_pretty filter for snippets and placeholders to optimize the human readability of a JSON string. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Virtual Attendants] Virtual Attendants are now first-class records (like groups and workers), with worklists, profiles, peek, ownership rights, etc. Previously, Virtual Attendant behaviors were owned directly by roles, groups, and workers; but this was creating clutter and confusion because some behaviors are related but there was no indication of this in the UI. Now, multiple Virtual Attendants can be created to contain any number of behaviors, and each VA can be owned by a worker, group, or role. All existing behaviors have been migrated to a new default Virtual Attendant record for each distinct owner. Virtual Attendants now show up in the global 'Search' menu, and clicking into a VA profile is where you will find the behavior trees and scheduled behavior. This also provides many new possibilities for future expansion; for example, Virtual Attendants can log errors to their profile in an easy-to-find tab. You can export and import behaviors between Virtual Attendants to place related behaviors together. [Messages/Performance/Snippets] The placeholder for message content is now lazy-loaded only when it is needed. This reduces extraneous queries from hitting the database when Virtual Attendants or snippets use message fields but ignore content. [Virtual Attendants/Macros/Profiles] The 'Virtual Attendants' button on profiles now organizes behaviors by Virtual Attendant. This makes it much easier to find the behavior you're looking for. Additionally, the macro menu no longer displays two lines for each entry; instead, behaviors are indented below their Virtual Attendant. This allows more options to be displayed in a smaller space, and it's less visually confusing. [Virtual Attendants/Activity Log] Activity Log entries that are created in response to Virtual Attendant actions will now log each Virtual Attendant as the actor. Previously, these entries were created as if the behavior's owner (e.g. worker, group) had performed them, which could lead to some confusion of accountability. Since Virtual Attendants are now first-class objects, they can be held accountable individually for actions they take. The Activity Log will also specify the name of the responsible behavior next to the Virtual Attendant. [Debug/Virtual Attendants] The /debug/export_attendants page will now export all behaviors grouped by Virtual Attendant. [Virtual Attendants/Scheduled Behavior] The 'Scheduled Behavior' tabs have moved to Virtual Attendant profiles. Previously, scheduled behavior was shown on worker and group profiles, since those records directly owned behaviors. The records targeted by scheduled behavior still show a summary at the top of their profile. [Mail/Reply/Virtual Attendants/Macros] The 'Virtual Attendants' button that is displayed when replying to a message will now display macros grouped by Virtual Attendant. [Setup/Virtual Attendants] The 'Setup->Configure->Virtual Attendants' page now displays a worklist of Virtual Attendants with links to profiles. Previously, a funky interface was used that required an admin to pick an owner from a list to view their owned behaviors in a tab. The new process is consistent with the way the rest of Cerb works. [Virtual Attendants/Snippets] Implemented a new jsonpath_set() function for snippets and placeholders to dynamically create deeply nested JSON objects from inside scripts. This is mainly useful for advanced Virtual Attendant actions that exchange JSON with remote apps and services. [Setup/Mail/Filtering/VAs] The Setup->Mail->Filtering page now shows the mail filtering behavior from all global Virtual Attendants on a single page. Previously, it was only possible to have a single global Virtual Attendant and its use was implied on this page. [Setup/Mail/Filtering/VAs] When an admin views the Setup->Mail->Filtering page for the first time, Cerb will offer to create the first global Virtual Attendant if one doesn't exist already. This improves the onboarding experience. [Virtual Attendants] Virtual Attendants may now be disabled, which treats all of their behaviors as being disabled. These behaviors will not trigger during events, and will now show up as macros on profiles. This makes it very simple to simultaneously deactivate related behaviors, which was tedious in earlier versions. Additionally, a worker can disable a Virtual Attendant while building and testing its behaviors. [Activity Log] Activity Logs for actor profiles (address, worker, group, virtual attendant) now display entries where the record was either an actor or a target of the activity. Previously, the log only showed actor activity for those records, and target activity for everything else. This meant that when viewing an address's activity from its profile, you wouldn't see log entries for when that address replied to conversations (as an actor), only when workers performed actions on that address (as a target). This change provides a more comprehensive view of the activities a record was involved with. [Activity Log/Groups] Group profiles now display an Activity Log tab. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can own custom fieldsets, providing them with long-term storage for arbitrary data on any record. This enables some very interesting new automation workflows. For instance, a monitoring Virtual Attendant can remember the last time it notified each worker about something by using a custom fieldset with a date on worker records. Similarly, a sales Virtual Attendant can keep track of its progress through an automated sales process with a custom fieldset that it saves on opportunities. [Virtual Attendants/Macros] Application-owned Virtual Attendants can now create custom behaviors for any record type. This allows global macros that are accessible by all workers, which greatly simplifies many workflows. Previously, these macros could only be created by VAs owned by groups, roles, or workers. [Virtual Attendants/Macros] Implemented a 'Custom virtual attendant behavior' event. This is the ideal place to implement generic behaviors that don't rely on a specific record type. For example, a Twitter Bot could schedule a recurring behavior to look for new @mentions, and it wouldn't make sense to target this behavior to any particular record. Previously, we had recommended to bind these generic behaviors on worker records just because it made them easy to manage from a profile. Now we recommend that these behaviors be migrated to Virtual Attendant profiles. [CHD-3113] [Support Center/Logins/Usability] When a Support Center page requires a login, a visitor will be redirected to their original destination after successfully logging in. Previously, the Support Center didn't even provide a login form to anonymous visitors if they requested a protected resource, it just displayed the default page. The new process should make it much easier to send contacts direct links to a specific ticket history, or protected knowledgebase articles. [Support Center/Usability] By default, the logo image on the Support Center is now a shortcut link back to the default page. [CHD-3441] [Support Center] When a customer views a ticket in the Support Center, there is now a reply button per message and no reply from is shown by default. Previously, a single reply form was always displayed at the top of the ticket which led to much confusion. [CHD-3148] [Support Center] When a customer replies to a ticket in the Support Center, the original message will now be automatically quoted in the response. [Platform/Popups/Usability] Popups are now limited to a height no more than 85% of the current browser height. Previously, popups could be so tall that they scrolled off the page. This made them difficult to work with; particularly when dragging them around. [Virtual Attendants/Macros/Plugins/Platform] Any Virtual Attendant behaviors that respond an event trigger will now be returned along with a snapshot of their data at their conclusion. This allows the caller to retrieve detailed information from those responders, and in an arbitrary way. [Virtual Attendants/Actions/Run Behavior] Virtual Attendant behaviors may now use a global '(Run behavior)' action. This is similar to 'Schedule behavior', except it runs the behavior immediately and allows the caller to retrieve values from the delegate behavior. For example, if one Virtual Attendant delegates another VA's behavior in order to create a task, then the caller can afterwards retrieve information about the created task from the delegate. This greatly improves the reusability of Virtual Attendants, as specialized VAs can handle routine actions, and helper VAs can delegate requests to them. This also makes it possible to build mediator VAs that listen on channels like SMS, IM, and Campfire; with requests being delegated to VAs that can do almost anything possible in Cerb: send reminders; create and complete tasks; check and change calendars; interact with Twitter, Facebook, JIRA; etc. [Virtual Attendants/Scheduled Behavior] Fixed an issue with the 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants. Disabled behaviors were not included in the list of available options, so if the actions referred to a behavior while it was disabled, and that action was edited and saved, then it would no longer refer to the behavior afterwards. Disabled behaviors are now displayed in the action, but they're marked as being disabled in case this is unintentional. [Virtual Attendants/Actions] When a Virtual Attendant action is missing, the behavior editor will now provide more helpful information, including an indication of what it was supposed to be. Previously, a blank action box was shown without providing any clue about what was missing. [Support Center/History/Reply] Fixed warnings created by the Support Center when a customer replies to a ticket without any attachments. [Virtual Attendants/Actions/Variables/Usability] In Virtual Attendants, the actions for setting variables are now displayed at the top of the available actions. As with other global actions, they are surrounded by parentheses. Previously these were sorted alphabetically with other 'Set' options, which made them more difficult to find. [CHD-1050] [Worklists/Custom Fields] When displaying a multiple value custom field as a worklist column, all of the selected values will now be displayed. Previously, only a single value per custom field was displayed based on what matched the search filters. [CHD-1086] [Custom Fields/Attachments] Implemented two new custom field types: file and multiple files. These types allow arbitrary attachments to be attached to records through custom fields. Internally, these fields use the attachments system and they store file IDs. [Virtual Attendants/Scheduled Behavior] The 'Schedule behavior' and 'Unschedule behavior' actions in Virtual Attendants are now global. They are available in all events and plugin-provided events do not need to implement them. Additionally, the action names are wrapped in parentheses so they appear at the top of the list of available actions. [Custom Fieldsets] Custom fieldsets may now be owned by the application. These fieldsets are readable by all workers but only configurable by admins. [Virtual Attendants/Custom Script] The 'custom script' condition in Virtual Attendant outcomes now a placeholders menu and script tester. [Calendars/Virtual Attendants] Calendar records can now also be owned by Virtual Attendants or the Application. [CHD-3460] [Virtual Attendants/Calendars] All Virtual Attendant behaviors may now use 'calendar availability' as a condition in outcomes. For example, this can be used to send different auto-replies based on availability. [CHD-2866] [Virtual Attendants] The 'new message on a watched conversation' event will now always include a ticket's owner even if they aren't a watcher. [Setup/Localization] A Setup->Configure->Localization page has been added for selecting the default date/time format for everywhere dates are displayed. Admins can choose between 12hr or 24hr formats, and this selection will cover all workers that don't have an established preference. [CHD-3064] [CHD-2973] [Preferences/Localization] Each worker can choose their desired time format (12-hour or 24-hour) from the 'Settings' page in their worker menu. [Virtual Attendant/Events] Added a new application-level 'Before sending worker message' event. Previously this was only possible at the group level. [Virtual Attendant/Events] Added a new application-level 'After sending worker message' event. Previously this was only possible at the group level. [CHD-3340] [Virtual Attendants/Mail] Virtual Attendant behaviors on the 'Before sending worker message' event may now add custom mail headers to the outgoing message. This was requested as a way to force read receipts, among other workflows. [Virtual Attendants/Behaviors] Virtual Attendant macro behavior may now be marked as public or private. A public behavior is visible to everyone with access to the VA (on profiles, etc). A private behavior is only visible to the VA itself. Private behaviors are useful for implementing helper macros within a VA that shouldn't be exposed to the outside world. These are generally used from 'Run behavior' or 'Schedule behavior' actions. [Virtual Attendants/Permissions/Events] Admins can choose which events each Virtual Attendant is capable of creating behaviors for. The options are 'allow all', 'allow these:', and 'deny these:'. This provides a way to offer limited Virtual Attendant functionality to workers with all use cases requiring prior approval. After the upgrade, all existing Virtual Attendants will default to 'allow all' events. [Virtual Attendants/Permissions/Actions] Admins can choose which plugin-provided actions a Virtual Attendant is capable of using in behaviors. The options are 'allow all', 'allow these:', and 'deny these:'. For example, the actions for JIRA and Twilio may be restricted to admin-controlled global VAs that worker VAs can delegate to. Actions that directly communicate with external apps and services can be restricted from use by most workers. After the upgrade, all existing Virtual Attendants will default to 'allow all' actions. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can specify a format for its output of either 'text' or 'JSON'. JSON output will be automatically be converted to an object when it is saved to a placeholder. This is particularly useful to simulate JSON responses from actions that perform API calls. [Virtual Attendants/Simulator/Actions] The Virtual Attendant 'Set custom placeholder' action can be configured to only set the placeholder when in simulator mode. This assists with providing test data in the simulator without affecting the outcome of a behavior when it runs normally. [Virtual Attendant/Simulator] Public worklist variables in Virtual Attendant behaviors can now be tested properly in the simulator. [Virtual Attendants/Actions] The 'Schedule behavior' and 'Run behavior' actions in Virtual Attendants can now include placeholders in the parameters being passed to the other behavior. [Virtual Attendants/API] Implemented '/rest/va/list.json' in the Web API for retrieving the list of Virtual Attendants that are visible to the current worker. This can include an 'expand' parameter with the option 'behaviors' to list all of the defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/123.json' in the Web API for retrieving the a particular Virtual Attendant. This can include an 'expand' parameter with the option 'behaviors' to list all of its defined behaviors. [Virtual Attendants/API] Implemented '/rest/va/behavior/123/run.json' in the Web API for running a 'Custom API request' Virtual Attendant behavior. This provides a standardized way for external applications and services to communicate with Virtual Attendants in Cerb. For example, a Campfire Bot can listen for messages in a chat room and relay a specific pattern (e.g. "@Cerb do something") to a specific VA behavior through the Cerb API. The response is a dictionary of all the behavior's values after running, including public and private variables. If a behavior retrieves a list of tickets, then their details will be available in the response for use outside of Cerb. [Virtual Attendants/API] Added a new 'Custom API request' event to Virtual Attendants. This can be utilized by app-owned and worker-owned VAs. These behaviors work similarly to macros, except they are only triggered through the API from external apps and services. This allows for interaction with Virtual Attendants through mobile text messages, email, instant messages, Campfire/Hipchat, mobile applications, browser plugins, etc. Custom API request behaviors always target the owning Virtual Attendant, and they provide an 'Add to API response message' action that appends text to the _response value of the API response. Using the _response value is optional, but it provides for generalized interaction with Virtual Attendants through the API. For example, an iOS app could display a list of all Virtual Attendants and their API-enabled behaviors. Running any behavior could prompt for its public parameters, and the response message could be displayed. It's also possible to use the 'custom placeholder' action for additional outputs. [Virtual Attendants/API] When a Virtual Attendants dictionary is converted to an array (e.g. for use by the Web API), any nested dictionaries will also be converted to arrays. Previously, if a behavior contained extra dictionaries (e.g. a list of records from a worklist search), it would return the IDs of those records but not their values. [Virtual Attendants/Simulator] When simulating the Virtual Attendant 'Run behavior' and 'Schedule behavior' actions, the simulator output will now show behavior variables being set. [Virtual Attendants/Simulator] Implemented Virtual Attendant simulator output for the 'Send email to notified worker' action in 'New notification for me' behaviors. [Setup/Mail/Parser] Raw email messages can be imported from Setup->Mail by pasting them into a textbox. This simplifies development, training, and evaluations. Previously, these messages had to be saved in the /storage/mail/new/ directory and then the parser scheduler job had to be manually run. [CHD-957] [CHD-3037] [CHD-3173] [Setup/Mail/Parser] Incoming mail messages that failed to parse can now be viewed, retried, or deleted from the Setup->Mail->Failed Messages page. Previously, administrators had to proactively monitor these files on the disk in the /storage/mail/fail/ directory, occasionally move them to /storage/mail/new/, and run the parser scheduled job manually in order to inspect the output. Failed mail is now displayed in a familiar worklist format with a peek popup to view each message source. [Web-API/Usability] Added a QR code image to the Web API Credentials peek popup. This allows mobile apps to quickly scan the QR code to copy the access and secret keys rather than requiring a user to laboriously type them. [Contexts/Messages] The generic label for Message records now shows the sender email, ticket mask, and ticket subject. Previously this just showed an unhelpful '(message)' placeholder. The label is used in Virtual Attendants, the Web-API, and the mobile app. [Contexts/Activity Log] Activity Log contexts now provide actor_* and target_* placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Activity Log] Activity Log contexts now provide a human-readable 'event' placeholder to describe the activity being logged. This can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Contexts/Workers] Worker contexts now provide is_disabled and is_superuser placeholders. These can be used in Virtual Attendant behaviors, snippets, and the Web-API. [Snippets/VAs/Workers] Added 'last activity date' to worker placeholders. [Devblocks/Workspaces/Charts/Plugin Development] The Devblocks HTML5 charting library now mediates all mouse interaction with the charts. Listeners can bind to 'devblocks-chart-click' or 'devblocks-chart-mouseover' to receive updates about user input. The returned event includes information about the closest data point to the mouse cursor, including chart coordinates. This saves the caller a lot of work when designing interactive charting elements. [Workspaces/Dashboards/Line Charts] Line chart dashboard widgets now display a horizontal line through the selected data point to make lateral comparisons easier. [Workspaces/Dashboards/Scatterplots] Scatterplot dashboard widgets now display crosshairs that intersect at the selected data point. This makes comparisons easier in both dimensions by creating quadrants. [Workspaces/Dashboards/Gauges] Gauge dashboard widgets now display their labels below the widget for uniformity. [Virtual Attendants/Variables/Lists] When a Virtual Attendant behavior has a list variable, the resulting worklist view_id will now be saved in the dictionary in the format var_name_view_id. This allows reuse of the underlying worklist for all kinds of functionality. Notably, it's currently used to send worklists to the mobile app. It could also overcome the 100 object limit of list variables now. [Calendars] Fixed an issue where long-running calendar events that started before and ended after the current month wouldn't be displayed as spanning the entire month. Mobile plugin [CHD-1056] [CHD-1108] [CHD-2378] [Mobile/Plugins] A 'Mobile Interface' plugin has been added to the Plugin Library. We had originally held off on creating a mobile interface because most workers use desktop computers and Cerb's UI workflow design is heavily dependent on multiple layers of popups to enable multiple actions from the same page. With the introduction of custom workspace pages in 6.0 and distinct Virtual Attendants in 6.5, the components of a mobile interface clicked into place. Rather than seeking to replace all the functionality in Cerb's normal UI, the mobile UI provides a access to previously curated content. The primary focus is on providing access to notifications, workspaces, and special Virtual Attendant mobile behaviors. The mobile plugin is built using jQuery Mobile, so there is a large list of supported devices: iPhone, iPad, Android, Windows Phone, Blackberry, WebOS, etc. We feel that a slim web interface is an ideal mobile strategy for Cerb because the functionality is contained within a plugin that is always in sync with the version of the main project. With mobile apps in various app stores using Cerb's API, users would constantly run into issues with version incompatibilities. Once logged in, the mobile interface can be accessed from any mobile browser by visiting the '/w' page at your normal Cerb URL. This can be bookmarked or saved to your device's home screen. [Mobile] Notifications can be viewed in the mobile interface. At the moment they open up a new browser tab to the full Cerb UI. In the near future we plan to implement mobile-friendly profiles for all record types. A count of unread notifications is displayed on a badge at the bottom of the app. [CHD-891] [Mobile/Workspaces] Workspaces can be viewed in the mobile interface. All workspaces that the current worker has access to will be displayed. The worker is prompted in several steps to select a workspace, a tab, and finally a worklist or a widget. The pages for tabs, worklists, and widgets provide shortcuts to jump back to the previous selections (for instance, from a widget to a page or tab). A filter box above the list narrows down the choices (for example, only showing pages with a specific owner). At the moment, clicking on a worklist row opens up the record in the full Cerb UI in the default browser. [Mobile/Virtual Attendants] Added a new 'Mobile behavior' event to Virtual Attendants. These behaviors can be run from mobile devices for any kind of workflow. For instance, mobile behaviors can create or search tickets, create tasks or notifications, search external systems for information, etc. Any public behavior variables will prompt the current worker for additional information. These behaviors can also be implemented on app-owned VAs so they are available to all workers by default. Mobile behaviors can respond with various types of messages that are displayed in a mobile device (e.g. text, html, maps, etc). [Mobile/Virtual Attendants] Virtual Attendants with mobile behaviors can be viewed in the mobile interface. All VAs that the current worker has access to will be displayed. When a Virtual Attendant is selected, a list of its available mobile behaviors is displayed. Selecting a behavior will prompt for the input of any public behavior variables (for instance, a mobile behavior to create a task would prompt for the task's name and due date). The response from the Virtual Attendant is displayed in a message reminiscent of a chat bubble. This functionality is incredibly powerful; Virtual Attendant powered mobile behaviors can provide workers with shortcuts to accomplish almost any workflow. Those behaviors are built inside Cerb's normal web interface. [Mobile/Plugin/iOS] The Cerb mobile interface now supports being added to the iOS home screen as a web app. This removes the location bar and footer from Mobile Safari so the experience feels more like a native app. Device-specific icons and start screens are provided (e.g. iPhone, iPad, retina). [Mobile] Implemented a sidebar panel in the mobile interface. This provides access to more functionality than can fit in the footer shortcuts: favorites, compose, pages, search, etc. [Mobile/Workspaces/Pages] The mobile interface now provides access to both workspaces and pages. The distinction is that a workspace is a page added by a worker to their navigation menu. Pages represent everything that a worker could choose to add to their menu as a workspace. [Mobile/Workspaces] The Workspaces shortcut in the mobile footer now displays a worker's workspaces in the same order that they appear in the full site. Previously this was displaying a list of all pages in alphabetical order. [Mobile/Profiles] The mobile interface now provides a profile page for every record type in Cerb. This makes it possible to gather more information without leaving the mobile site. Profiles also provide automatic links between related records. For example, from a ticket profile you can quickly view the sender's profile, their org's profile, the assigned group's profile, the ticket owner's profile, etc. [Mobile/Search] The mobile interface now provides a 'Search' page in the menu panel. This displays a list of every record type in Cerb. When a record type is selected then a mobile worklist is displayed with the matching records. Clicking on a record displays its mobile profile. The profile also contains a link to open the record in the full site. This improvement makes the mobile interface very useful for workers who need to perform quick record lookups while away from their desk. [Mobile/Workspaces] Mobile worklists now display their current filters above the list. Clicking a filter removes it. [Mobile/Workspaces] New filters can be added to mobile worklists using quick search functionality. Clicking the filters button above the list opens a popup that displays all searchable fields. [Mobile/Workspaces] Mobile worklists can use existing filter presets. After clicking on the filters button, all presets are displayed as buttons in a popup. Clicking one of these buttons will instantly replace the filters. This is particularly useful in a mobile environment, especially when performing ad-hoc searches rather than using prebuilt workspaces. [Mobile/Workspaces] Mobile worklists can be sorted in ascending or descending order on any available column. The field currently being sorted by is displayed above the list, and the arrow next to the label indicates the sort direction (i.e. asc, desc). [Mobile/Workspaces] Mobile worklists can be paged forward and backward. On subsequent pages, an option is provided to instantly jump back to the first page. In a slight deviation from the full UI, paging displays the current and total pages along with the total number of results. In the full UI, paging displays the current position in the results and the total number of results (i.e. no indication is given for the total number of pages). [Mobile/Workspaces] Mobile worklists can now display any number of fields for each row. Since screen space is generally limited on mobile devices, these fields are not displayed as horizontal columns like in the full UI, but as smaller vertical rows beneath each result's heading. At the moment, the displayed fields are based on useful defaults for each record type. In the near future this feature will support the ability to decide which fields should be displayed per worklist or worklist type. This functionality is actually more advanced than the main UI, since it uses the placeholders from Virtual Attendants and snippets instead of being confined by the results from the database. In the main UI, only a limited amount of information from related records is available as columns (e.g. ticket -> organization). With the placeholder approach, even content at the end of a long chain of related records can be displayed (e.g. ticket -> first message -> sender -> org -> custom field). [Mobile/Virtual Attendants] Mobile Virtual Attendant behaviors now return their response on a new page. Previously the response was displayed below the submit button. The state of the response page is now cached so that the back button works properly. This allows responses to include links to new records, with the back button returning to the response without re-running the behavior. By not caching the behavior page, the mobile app can now instantly see any changes made to the behavior in Cerb. [Mobile/Workspaces] Mobile worklists can now be paged, sorted, filtered, and searched in place using Ajax. Previously, these actions were initiating a full page reload due to the way that popups work in jQuery Mobile. The reload was displaying a 'flash of unstyled content' on mobile devices. [Mobile/Virtual Attendants] Mobile Virtual Attendants can now return different types of responses. Previously, all messages had to be text-based. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return HTML responses. Any provided Javascript is evaluated, which makes interactive responses possible. For example, a Virtual Attendant can return a real-time chart using an HTML5 canvas. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return interactive worklists as responses. Previously, behavior variables that contained a list of records had to be displayed as text with links back to each record. Now any list variable on the behavior can be sent to a worker's mobile device. This displays a mobile worklist that's sortable, pageable, and filterable. The results also display properties about each record, and clicking on a record will display its mobile profile. The back button can be used to return to the worklist. For example, a mobile VA can send a list of tasks or tickets to a worker, and the worker can use that worklist in place as if they had searched for those results themselves. [Mobile/Virtual Attendants] Mobile Virtual Attendants can return multiple responses to a single request. For example, a text response can state "Here are the results I found for you" and a second response can display the results as an interactive worklist. JIRA plugin [JIRA/Plugins] Added a 'JIRA Integration' plugin to the Plugin Library. This automatically synchronizes JIRA project and issue information. It also extends Virtual Attendants with the ability to remote control JIRA data. JIRA Projects and Issues can be accessed from Cerb's global Search menu. JIRA data can also be linked to other records (e.g. addresses, orgs) to track customer interest in issues and provide Virtual Attendants with data for following up on that interest. [JIRA/Virtual Attendants] Implemented an 'Execute an API request to JIRA' action in Virtual Attendants. Rather than being restricted to a few options, this can make any API calls to JIRA that the given credentials are authorized to do. For this reason, it is important to restrict this action to only trusted Virtual Attendants. Other VAs can still delegate actions to the behaviors on trusted VAs with access to JIRA. Check the online documentation for examples. [JIRA/Issues/VAs] Implemented Virtual Attendant custom behaviors for JIRA Issue records. For example, a 'Resolve' behavior could close a JIRA issue from Cerb. [Less]

If you'd like to send yourself a daily task list (for instance, as an early morning reminder), here's a helpful little VA to do that for you. First, download the attached Task Mailer VA.txt file. Go to your Virtual Attendant area (click on your name ... [More] in the top right, then click on Virtual Attendants) and import the contents of the downloaded file. To import the VA, click on Create Behavior, then select the import tab and paste the contents there, then save it. You may want to change the From address, so click on the bubble that says "Send task summary to email" and set the From address, if desired. To schedule this behavior, go to your profile (click your name, click My Profile), and then click on the Virtual Attendant dropdown under your picture (top left). Select the "Send today's task reminders to email" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. That should be it for a task reminder, but you can use the same concepts shown in this sample VA to send periodic lists of overdue tickets, upcoming sales opportunities, etc. [Less]

If you'd like to send yourself a daily task list (for instance, as an early morning reminder), here's a helpful little VA to do that for you. First, download the attached Task Mailer VA.txt file. Go to your Virtual Attendant area (click on your name ... [More] in the top right, then click on Virtual Attendants) and import the contents of the downloaded file. To import the VA, click on Create Behavior, then select the import tab and paste the contents there, then save it. You may want to change the From address, so click on the bubble that says "Send task summary to email" and set the From address, if desired. To schedule this behavior, go to your profile (click your name, click My Profile), and then click on the Virtual Attendant dropdown under your picture (top left). Select the "Send today's task reminders to email" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. That should be it for a task reminder, but you can use the same concepts shown in this sample VA to send periodic lists of overdue tickets, upcoming sales opportunities, etc. [Less]

If you'd like to send yourself a daily task list (for instance, as an early morning reminder), here's a helpful little VA to do that for you. First, download the attached Task Mailer VA.txt file. Go to your Virtual Attendant area (click on your name ... [More] in the top right, then click on Virtual Attendants) and import the contents of the downloaded file. To import the VA, click on Create Behavior, then select the import tab and paste the contents there, then save it. You may want to change the From address, so click on the bubble that says "Send task summary to email" and set the From address, if desired. To schedule this behavior, go to your profile (click your name, click My Profile), and then click on the Virtual Attendant dropdown under your picture (top left). Select the "Send today's task reminders to email" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. That should be it for a task reminder, but you can use the same concepts shown in this sample VA to send periodic lists of overdue tickets, upcoming sales opportunities, etc. [Less]

If you'd like to send yourself a daily task list (for instance, as an early morning reminder), here's a helpful little VA to do that for you. First, download the attached Task Mailer VA.txt file. Go to your Virtual Attendant area (click on your ... [More] name in the top right, then click on Virtual Attendants) and import the contents of the downloaded file. To import the VA, click on Create Behavior, then select the import tab and paste the contents there, then save it. You may want to change the From address, so click on the bubble that says "Send task summary to email" and set the From address, if desired. To schedule this behavior, go to your profile (click your name, click My Profile), and then click on the Virtual Attendant dropdown under your picture (top left). Select the "Send today's task reminders to email" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. That should be it for a task reminder, but you can use the same concepts shown in this sample VA to send periodic lists of overdue tickets, upcoming sales opportunities, etc. [Less]

Release notes for Cerb 6.4 Cerb (6.4) is a major functionality update released on June 7, 2013. It contains over 118 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.4 [Dashboards/Widgets/Usability] ... [More] Dashboard widgets now display a single icon in the top right with a dropdown menu. This provides a place to add more options. Previously, every option was an icon, which limited the amount of space available to display the widget title. The new menu will be used to provide options like duplicating widgets or exporting their data. [Dashboards/Widgets/Gauges] Gauge widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Counters] Counter widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Charts] Chart widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Subtotals] Subtotal widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Scatterplots] Scatterplot widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Pie Chart] Pie chart widgets can now 'Export Data' to JSON or CSV. [Web-API/Usability] When using the 'expand' option in the Web-API, the extra records no longer contain extraneous fields like 'global timestamp' and the currently active worker. [Web-API/Authentication] Refactored the Web-API so that any code that checks for the 'active worker' may be used in API calls. The Web-API doesn't require sessions or cookies. Previously, the API implemented its own authentication, and the use of code that checked for a worker session would fail. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Pages. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Tabs. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Widgets. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::intClamp($n, $min, $max) for conveniently constraining a numeric value within a given range. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::strFormatJson($json) to format JSON in a human-friendly output. Nested properties are indented, and one key/value pair or array element is displayed per line. [Workspaces/Code Cleanup] Fixed an issue where worklist and subtotal widgets created an extra worker_view_model record in the database during rendering. There should be one entry per worklist-based series. [Workspaces/Widgets/Code Cleanup] Improved the way that widgets store worklist datasource information. Previously, Cerb stored a C4_AbstractViewModel object for each worklist datasource, serialized in PHP format, and base64 encoded in the widget properties. This was bloated and not very human friendly. It included a lot of information that could be reconstructed from worklist contexts. Worklist information is now stored by widgets in an easily readable JSON format, without any extraneous data, encoding, or serialization. At the same time, uniquely identifying information (like worklist IDs) are no longer used in widget properties, which paves the way for many new and highly anticipated features, like the ability to copy or share any widget. The format of existing widgets will be automatically converted during the upgrade process. [Workspaces/Widgets/Code Cleanup/Performance] Removed some unnecessary code that ran when configuring several workspace widgets: counters, gauges, subtotals, worklists. Several of these were derived from the original charting widget, and they emulated pulling a list of fields through Ajax every time the context (record type) of the worklist was changed in config. That information isn't used by any of these widgets, and its retrieval created a few needless calls to Cerb and the database. [Workspaces/Widget/Export] All workspace widgets now support the ability to export their configuration to a plaintext format (JSON). This option may be accessed by clicking the configuration menu in the top right of the widget, and selecting 'Export Widget'. Using this feature, widgets may be saved and transferred electronically; providing the beginnings of a community exchange for useful widgets. [Workspaces/Calendars] Migrated calendar workspace tabs to the new worklist datasource format. [Virtual Attendants/Worklists] Migrated Virtual Attendant 'Set List Variable' actions to the new worklist datasource format. This is a prerequisite for creating VA import/export functionality. [Workspaces/Dashboard/Widgets/Import] Dashboard widgets may now be imported from the 'Add Widget' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and clone widgets, and to share widgets between workers or Cerb installations. This was the last missing piece blocking an official repository of widgets from being created. [Workspaces/Dashboards/Widgets/Import] When importing dashboard widgets, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the widget before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a counter widget that reports on the number of overdue tasks owned by a specific worker can now prompt for which worker to use when being imported. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::jsonGetPointerFromPath() for making arbitrary changes at any depth to a JSON object by using an XPath-like path. This is used by the Virtual Attendant and Dashboard Widget import functionality to allow guided customizations prior to import. This helper method can be reused anywhere that similar functionality is required. [CHD-2530] [CHD-2688] [Virtual Attendants/Export] All Virtual Attendant behaviors now support the ability to export their decision trees to a plaintext format (JSON). This option may be accessed by clicking on the behavior and selecting 'Export Behavior' from the menu. Using this functionality, VA behaviors can now be duplicated, shared, or saved. The project can also maintain an official repository of useful VA behaviors that can be easily installed. [Virtual Attendants/Import] Virtual Attendant behaviors may now be imported from the 'Create Behavior' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and copy behaviors, and to share behaviors between groups, workers, or Cerb installations. For example, once setting up a complex auto-responder behavior for a group, it can be quickly copied to several other groups without having to tediously repeat the whole process of adding decisions, outcomes, and actions. This also makes it possible for the project to maintain an official repository of useful behaviors that can be easily imported into any Cerb instance. [Virtual Attendants/Import] When importing Virtual Attendant behavior, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the behavior before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a custom behavior that assigns tickets to a particular worker can now prompt for which worker to use when the behavior is imported in a new environment. [Debug/Virtual Attendants] The Virtual Attendant 'Export Behavior' option on the /debug page now uses the same JSON format as 'Export Behavior' does in the app. Previously, this used a special XML format which was only intended for human review but not importing. The new format allows imports by developers and QA to assist customers with troubleshooting. The advantage of using this option is that it exports all behaviors at once. It may also be used by administrators to review or make backups of all VA behaviors. [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/list.json' method to the RESTful Web-API. This retrieves a list of all workspace pages accessible by the current worker; owned by them, their groups, or roles. The 'expand' parameter includes additional information about each page's owner, tabs, widgets, or worklists. This is very useful for bringing workspace data into external interfaces (such as mobile apps). [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/123.json' method to the RESTful Web-API. This retrieves a specific page. The 'expand' parameter includes additional information about the page's owner, tabs, widgets, or worklists. [Web-API/Workspaces] Implemented a 'GET /workspaces/tabs/123.json' method to the RESTful Web-API. This retrieves a specific worklist tab. The 'expand' parameter includes additional information about widgets, widget data, or worklists. The data for all widgets on the tab may be retrieved in a single request, which makes it very easy to empower remote scripts and apps with the ability to monitor and report on Cerb dashboards. For example, a dashboard tab could summarize information about a series of servers in a datacenter, and a remote script could check those metrics against thresholds, whether they're counters, gauges, charts, etc. This is useful, since Cerb dashboards are very informative but they don't get a worker's attention if they aren't proactively monitored. [Web-API/Workspaces] Implemented a 'GET /workspaces/widgets/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace widget, and always includes the widgets raw data. This has all the same advantages for remote monitoring and reporting as pulling a workspace tab. [Web-API/Workspaces] Implemented a 'GET /workspaces/worklists/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace worklist. The response provides search results with support for sorting and paging. By setting up the desired filters on the Cerb dashboard, a remote API consumer doesn't have to concern itself with filtering results. For example, a remote app could display the 'Available tickets' worklist from an existing workspace, which may use a dozen filters to highlight the appropriate tickets. This not only saves the API consumer a lot of work in listing that information, but it also means that remote apps don't need to update every time the filters on the underlying worklist change. [CHD-2930] [CHD-3082] [Mail/POP3/Scheduler] A failing POP3/IMAP mailbox will no longer be auto-disabled after 5 consecutive failures. Instead, a delay of two minutes will be incurred for each consecutive failure up to a maximum delay of 30 minutes. This ensures that the mailbox will be retried within a reasonable amount of time. Previously, mailboxes could remain disabled over a weekend if no admins were available. Saving a mailbox in setup will reset the failure and delay counters. [Setup/Mail/POP3/Usability] Failing POP3 mailboxes are now marked with an icon in "Setup->Mail->POP3 Accounts". A message is also displayed when editing a failing mailbox that reads "Error! This mailbox has failed to check mail for (n) consecutive attempts". This should help admins spot potential issues more easily. [Setup/Mail/POP3/Aesthetics] Improved the process of deleting a mailbox from "Setup->Mail->POP3 Accounts". This is now more consistent with the rest of the app. Previously, you had to check a box at the bottom of the form to delete the mailbox. Nothing else in Cerb works like that. [Plugin Library/Setup] The 'Download updates' button in the Plugin Library will now automatically download any updates for all installed plugins. Previously, it just updated the version information but an admin had to update each plugin by clicking a button in the list. If a '.git' development directory exists in a plugin then it won't be automatically updated (as this would interfere with development). [Plugin Library/Upgrade/Platform] When upgrading from the /update page, Cerb will now attempt to download the latest version of all installed plugins from the Plugin Library. This should spare admins from having to manually update and re-enable all third-party plugins after an upgrade. [Custom Fieldsets] Custom fieldsets allow groups of related custom fields to be added to records in order to classify them. Previously, adding a new custom field to a type of record (e.g. tasks, tickets) would always display that field on every record. This led to a lot of clutter when custom fields were only used by a single group, worker, or Virtual Attendant behavior; and when a custom field was only related to a subset of records of the same type. With fieldsets, you can optionally add multiple sets of custom fields to a specific record. For example, an asset record could have a 'Car' fieldset added to it, with fields that describe mileage, color, make, model, VIN, etc. Another asset record could have a 'Computer' fieldset, with fields for CPU speed, RAM, serial #, etc. Both of these records would be assets, but they would be classified separately. These fields would not be mixed between the two records. It is still possible to have global custom fields for all records of the same type, as before; it's just no longer the only option. Fieldsets can be owned by roles, groups, or workers. Existing group-based custom fields will be converted to group-owned fieldsets during the migration. Fieldsets are managed in the peek popup and can be added using the 'Add Fieldset' button which displays a menu of available fieldsets. A fieldset can also be deleted by clicking the red X button that is displayed when hovering over any of its fields. [Groups/Custom Fields] The 'Custom Fields' tab on Group Setup now manages the custom fieldsets owned by the group, rather than individual global fields. [Custom Fields/Usability/Contexts] Contexts (record types) can now provide a hint that they implement custom fields for their records. This allows Cerb to only show custom field options for records that support them. Previously, the 'Custom Fields' page in Setup displayed many record types that had no way to display or edit such fields. [Profiles/Usability/Aesthetics] On the profile for every record type, the toolbar has been moved to the very top of the page. Since custom fieldsets are now displayed at the top of profiles, this helps the page flow better. [Custom Fieldsets/Subtotals] Since custom fieldsets have increased the length of many custom field names, the title of the subtotals sidebar on worklists will now be wrapped when necessary. [Custom Fieldsets/Bulk Update] Custom fieldsets and their fields may be set from the Bulk Update popup for any records that support them. [Knowledgebase/Bulk Update/Custom Fields] Custom fields may now be set on knowledgebase articles using Bulk Update. [Mail/Compose/Custom Fieldsets] Custom fieldsets may be set when composing mail. This solves a long-standing issue where desired custom fields couldn't easily be set when creating a ticket, and instead had to be set by subsequently editing the newly created record. Additionally, custom fields could only be set based on the group associated with the ticket. Now, all custom fieldsets are available when creating a ticket, irrespective of factors like the group. This also simplifies the compose popup by not displaying custom fields that aren't needed. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can now utilize custom fieldsets on conditions and actions. [Mail/Reply/Custom Fields] When replying to a ticket, custom fields will no longer be displayed at the bottom of the form. The main problem with the previous approach is that it led to overwriting any custom field changes that took place on the same record while a long reply was being drafted. This is because the form set the value of all fields, rather than only setting a few specific fields. This functionality can be reintroduced later in a better way. For now, custom fields may be set from the peek popup using the edit button after replying to a ticket. [Custom Fieldsets/Worklists/Subtotals] Subtotals and filters on worklists will now automatically adapt the available custom fields based on any active fieldset filters. For example, if there are 10 possible fieldsets for tickets, then you'll see a lot of custom fields for filtering or subtotaling a worklist. If the same worklist is filtered to a specific kind of fieldset, then only custom fields from that fieldset will be displayed when configuring the worklist. This helps progressively reduce clutter once the intentions of the worker are known to Cerb. [Platform/Update] When using the /update page to update Cerb, the lockfile being written to the temp directory was prefixed with 'c4' (from Cerb4). This has been changed to 'cerb' instead. [Choosers] The chooser popup is now given information about the record being displayed when it was opened, which allows it to customize itself appropriately. For example, a custom fieldset chooser should only show fieldsets for the given context (e.g. task, ticket). Other choosers can use this information to predict a worker's intentions and save them time. [Workspaces/Dashboards] Fixed an issue on dashboards where worklist-based counters and gauges didn't load values from custom fields that weren't in the filters. For example, a counter intended to SUM the value of a custom field may have displayed '0' even though several values existed. The reason for this is very technical, but has to do with how worklists intelligently use the most efficient way to load values based on how they are needed. When filtering, a slower LEFT JOIN is needed. For just displaying a value, a quick subquery is used without any joins. Counters and gauges always need to join values for aggregate functions. [Workspaces/Dashboards] Fixed an issue on worklist-based chart widgets where custom fields as axes may not display the proper values when they aren't used as filters on the underlying worklist. This had to do with how worklists interact with the database. The process is now more intuitive and custom fields can be selected without any other considerations. [Workspaces/Dashboards] Fixed an issue where scatterplots didn't display any plots if the dataset only had a single sample. [Platform] Removed the concept of ONDEMAND_MODE from the code, since this is handled better through a forked version of the project now. [Workspaces/Dashboards/Worklists/Usability] Worklists that are used as widgets on dashboards now label each field they display. Previously, a worker had to constantly refer to the horizontal order of the headings to figure out the vertical values being displayed for each row. The new approach uses a little more space but improves usability dramatically. [Platform/Plugin Development] The devblocks-dao.php script in /install/extras/sdk will now assist with creating the initial code and templates for contexts, profiles, and peeks. It also adds several useful virtual fields to the generated worklist: context links, watchers, and 'has fieldset'. Custom fields are enabled by default. The 'delete' option on peeks uses the two-step verification rather than the gaudy browser confirmation popup. [Calendars] Calendars are now distinct records that may be owned by workers, groups, or roles. Previously, events were directly owned by a worker and were collectively referred to as a calendar, although no record existed, and each worker could only have a single calendar. Any number of calendars may now be created, and owners may be responsible for several. For example, a group can define its collective working hours (e.g. for SLAs) as a group-owned calendar. The upgrade will create a calendar for each worker and assign their existing events to it. [Calendars/Events/Profiles] Fixed an issue where a calendar event profile page didn't refresh after the record was updated from the 'Edit' button. [Calendars] Calendars now have datasource extensions which are responsible for retrieving events for a given date range. Previously, events always had to be manually created. Now they can come from worklists, or synchronize from other apps and services. [Calendars/Platform/Plugins] Implemented DevblocksCalendarHelper::getCalendar($month, $year) which generates a calendar grid for use by multiple areas of functionality. [Calendars/Worklists] Calendars that display worklist-based events now provide the ability to create and edit records of that type. For example, a calendar that displays tasks by due date can be used to schedule new tasks or reschedule existing ones. This time sequence workflow is much easier to accomplish visually rather than with a worklist. [Devblocks/Platform/Code Cleanup] The timezone list returned by DevblocksPlatform::getDateService() is now provided by PHP's built-in timezone_identifiers_list() rather than from a hardcoded list. [Calendars] A calendar may now have multiple datasources. For example, a task calendar can display open tasks as one datasource in green, and completed tasks as a second datasource in gray. These colored events would be displayed on the same calendar in order to communicate more information at the same time. [Calendars] Calendars can toggle the ability of workers to create manual events in addition to those provided automatically by datasources. For example, on a calendar that displays task or invoice information, it is likely undesirable to allow manual events to be added to the calendar since all of the data is coming from worklists. [Calendars] Calendars can toggle the ability to allow automated synchronization from other datasources. On a calendar of manual events, synchronization may be disabled to simplify the calendar's configuration. This will hide the external datasource options. [Workspaces/Dashboards/Plugins] Dashboards now send a 'dashboard_heartbeat' event to all widgets every second. This can be used for timed behavior (clocks, etc) without having to implement timers for every widget. With timers for each widget, it is possible for two clocks on the same page to update at different intervals, which is visually distasteful and distracting. [Dashboards/Countdown] A new countdown widget is available on dashboards. You can use these widgets as gentle reminders of upcoming events. For example, on a development dashboard you can display a countdown to the next milestone (an iteration or release). On a sales dashboard, you can display the time left in the current period (quarter, year). [Dashboards/Clock] A new world clock widget is available on dashboards. The clocks support 12-hour or 24-hour display, and the closest timezone can be quickly selected from the list of major cities organized by continent and country. These widgets are particularly useful for coordinating with international team members or sales prospects. [Calendars/Events] Calendar event worklists can display their parent calendar as a column, and filter or subtotal by calendar. This is particularly useful in calendar event choosers. [Calendars/Workspaces] Existing calendar-based workspace tabs have been automatically converted to calendar records. These tabs now have access to all the functionality improvements related to calendars. An existing calendar may now be displayed on a workspace in a few clicks, and the same calendar may be displayed in multiple places and by multiple workers. [Calendars/Workspaces] The events from calendars on workspace tabs are now clickable. Previously, clicking on one of these events did nothing, which made it difficult to do anything useful with the calendar other than looking at it. Each event will open its peek popup depending on its type (e.g. tasks, tickets, events). [Calendars/Workspaces] Calendars displayed as workspace tabs may be edited directly from from the workspace by clicking on the gear icon. This removes the need to leave the workspace to modify the underlying calendar. [Calendars/Worklists] Calendars that use worklist-based datasources can now set availability (free/busy) and end dates for the events they generate. This means that in some situations, a datasource (like assigned tasks) may increase or reduce availability. [Calendars/Dashboards] Calendar widgets are now available on dashboards. These widgets offer a quick summary of a calendar without taking up much screen space. There’s a count of events occurring for each day, and the full list is displayed when hovering. You can also click each event to open its peek popup and modify it; and those changes will be immediately reflected on the calendar. This allows you to get more work done from your dashboard — rescheduling tasks, chasing overdue invoices, etc. You’ll also notice a small gear button at the top of the widget. If you have edit permission on the calendar, you can modify it directly from your dashboard as well. [Calendars/Availability] Rather than displaying a fixed calendar as before, worker profiles now display an Availability Calendar which takes the events from an existing calendar and converts them into availability windows. This is what a Virtual Attendant sees when it’s scheduling a task or looking for an available worker. Each worker can elect one of their calendars to determine their availability, which then becomes visible on their profile. This approach is particularly helpful in situations where a worker’s schedule may change frequently between various shifts. A calendar for each shift can be created, and when the schedule changes it’s a single click to activate a new calendar. To temporarily remove their availability entirely (e.g. vacation, leave of absence, paternity, sabbatical, code marathon), a worker can simply break the link between their availability and an existing calendar. They don’t need to modify or delete any of the existing events, which makes it much easier to resume working later on. [Calendars/Virtual Attendants] Virtual Attendants can set date-based behavior variables using calendars. This allows scheduling based on "work hours" to automatically skip nights, weekends, and holidays. [Calendars/Custom Fields] Added custom fields to calendar event records. [Calendars/Virtual Attendants] Virtual Attendants behaviors that use the 'Worker calendar' condition have been migrated to the new 'Worker availability' condition instead. This compares against each workers' preferred availability calendar. [Calendars/Workers/Worklist] Converted the use of the 'worker calendar' worklist filter to the new 'worker availability' filter. Rather than checking a single calendar, this now checks workers' preferred availability calendar. [Calendars/Events] When adding new records from a calendar event worklist, the current worker may choose to add the event to any of their writeable calendars. [Calendars/Events] In a calendar event worklist, the calendar field now links directly to its profile. [Calendars/Usability] Calendars that display worklist-based content now provide a way to create new records of those types. For example, a task-based calendar can be used to schedule new tasks, in addition to rearrange existing ones. This functionality is available in all the places where calendars are shown: calendar profiles, availability calendars, workspace tabs, and ashboard widgets. [Virtual Attendants/Calendars] Virtual Attendants can now set any date-based fields, custom fields, or behavior variables using calendars. [CHD-3356] [Virtual Attendants/Tasks] Fixed an issue where a date-based behavior variable couldn't be used to set the due date of the 'Create Task' action in Virtual Attendants. Text-based variables worked fine. [Virtual Attendants/Simulator] The Virtual Attendant simulator will now properly set custom fields using placeholders on the 'Create Task' and 'Create Ticket' actions. These values were actually set properly in behaviors, they just didn't translate in the simulator. [Calendars/Web-API] Implemented '/rest/calendars/123.json' in the Web API for retrieving calendar details. This can include a query parameter named 'expand' with the options 'weeks' (week and day data for drawing a calendar), 'events' (flat list of events during the calendar month), and 'weeks_events' (events grouped into days). Additionally, the arguments 'month' and 'year' may be provided to change the time period. [Calendars/Web-API] Implemented '/rest/calendars/list.json' in the Web API for retrieving a list of all accessible calendars for the current worker. [Calendars/Web-API] Implemented '/rest/calendars/search.json' in the Web API for searching calendars. [Calendars/Events/Recurring] Recurring calendar events are now virtualized. Rather than generating thousands of event records, recurring events are generated on-the-fly for any given date range. This cleans up a lot of redundant clutter in the database, and it also means that you can advance a calendar 10 years ahead and still see your recurring events, where previously such events were limited to displaying through the end of the current year (plus one month). The scheduler job for calendar scheduling is no longer needed and has been removed. Existing recurring events have been converted to the new format. [Calendars/Events/Recurring] The process of creating recurring events no longer relies on a rigid UI that forces a choice between daily, weekly, monthly, or yearly repetition. Recurring events may now be easily and quickly created using natural language, like "Weekdays", "Monday", "December 25", "15th", etc. Previously, it was not possible to set up recurring events like the US Holidays of Labor Day and Thanksgiving where they change every year. Now, recurring events can be created with patterns like "fourth Thursday in November" and "first Monday of every month". [Calendars/Events/Recurring] Recurring calendar events may now specify a timezone to be used when scheduling by relative times (e.g. 02:00 to 20:00). Previously, the timezone of the current worker was always assumed, but this made it difficult to deal with times that were intentionally in another timezone. Now a recurring event can be scheduled in London time while working in Los Angeles time. [Snippets/Worklists/Usability] Snippet worklists will no longer display the snippet preview for each row (no other record type did this, and it's available from peek). However, it will still be displayed on the snippet chooser where it remains useful. [Workspaces/Worklists/Usability] Worklists now determine the width of their columns without regard for the length of column headers. This was becoming a problem when long field names (particularly from custom fieldsets) were forcing columns to be much wider than their contents, which stole width from other columns that needed it more. For example, a column heading of "Organization SLA Is Expired" likely only needs to display values that are Yes/No. Under the new behavior, this column would now be narrower than its heading, and the extra space would be given to other columns. This functionality is also useful if you want to display many columns, because columns without any values in them won't waste screen space by displaying their full heading. [Virtual Attendants/UI/Worklists] Implemented a new Virtual Attendant event for '[UI] While displaying a worklist'. This allows behaviors that automate modifications to worklists in the browser using jQuery actions. These behaviors can target worklists by type (e.g. ticket, task) as well as unique identifier. This means modifications can be made to all worklists of a certain type anywhere in Cerb (widgets, workspaces, search, choosers), or such changes can be targeted to a specific instance of a worklist (e.g. just ticket choosers, or a single task worklist widget). These VA behaviors can be owned by Cerb, roles, or workers. A global behavior (e.g. role-owned) would be applied to displayed worklists for all workers. There are many use cases for this event: a date-based custom field can be colored red when overdue; a priority custom field can display colors for each level; relative dates (e.g. 2 hours) can be converted to absolute dates (e.g. June 3 2013 2pm); column headers can be relabeled; etc. [Worklists/Virtual Attendants] When a Virtual Attendant modifies a worklist, a robot icon is now displayed next to the worklist's title. Clicking this icon will display a list of the behaviors that were executed against the list (e.g. color rows by priority; color overdue due dates red; display dates as date+time). [Dates/Calendars/Usability] Implemented smart date input fields. Previously, you could only enter relative ("+2 hours") or absolute ("Jan 9 2020") dates into these fields. Now it's possible to schedule a relative date in 'working hours' using any calendar (for example, following an SLA schedule). This works whether you're scheduling a task due date, a ticket reopen, any custom field, or anything else. You can press ENTER in a date field to have any date text automatically converted into your current timezone. This allows workers to verify the final date before saving the record (where before, the relative date text was sent blindly to the server). [Dates/Calendars/Usability] As an additional convenience on smart date input fields, you can also convert dates and times from other timezones into your current timezone. For example, if you're in Los Angeles and you need to schedule a due date for 2pm tomorrow in London time, you can type "tomorrow 2pm Europe/London" into the date field and press ENTER. As a shortcut, you can also type "tomorrow 2pm Lon" and autocomplete the rest. [Tasks/Profile/Usability] The task profile page now makes it more obvious at a glance that a task is completed. In the properties, the status field will be colored green with a checkmark icon. [Orgs/Worklist] Fixed an issue where deleting an organization could result in a blank worklist. [CHD-3344] [Mail/Setup/Reply-To] When adding a new 'Reply-To' address, a 'delete' button will no longer be displayed. The option to delete should only be available when editing. [CHD-3311] [Virtual Attendants/Schedule Behavior] Virtual Attendants may now schedule the date for another behavior based on placeholders. [CHD-3353] [Virtual Attendants/Mail] Fixed the 'sender is worker' condition on 'New message on a group conversation' Virtual Attendant events when the ticket is created by a sender that is also a worker. [CHD-3338] [Virtual Attendants/Mail] Fixed an issue in Virtual Attendants where the setting of the 'Set Organization' action on the 'New message on a group conversation' was blank after re-editing. [CHD-3336] [Mail/Subtotals] Ticket worklists may now be subtotaled by the 'Last Action' field. The possible actions are New Ticket, Worker Replied, or Recipient Replied. [CHD-3335] [Tickets/Bulk/Usability] Using 'Bulk Update' on a ticket worklist will set the value of the 'Updated' field to the current time. This was requested as a way to identify tickets after the fact that were changed in the same batch. [CHD-3332] [Mail/Pile Sorter/Merge] When pile sorting a ticket worklist, the 'merge' action is now available for sub-piles. Previously if you pile sorted by sender, you could merge by domain but not by individual senders. [Calendars/Watchers] When a worker adds a new event or recurring event to a calendar, a notification will be sent to any watchers of that calendar. This makes it really easy for a worker to notice when someone adds an event to their calendar for them. [Mail/Reply/Keyboard] When replying to a ticket, the Ctrl+Shift+Enter keyboard shortcut will instantly send the message. [Mail/Reply/Keyboard] When replying to a ticket, three new shortcuts will automatically set the status of the ticket. Ctrl+Shift+O (open), Ctrl+Shift+W (waiting), Ctrl+Shift+C (closed). This saves extra mouse clicks, or the use of TAB to navigate down the page. [Mail/Reply/Dates/Keyboard] When replying to a message and entering a 'wait until' date, the Ctrl+Shift+Enter shortcut will convert the date and then send the message in a single keystroke. [Workspaces/Export] Workspace pages and tabs support the ability to export their configuration to a plaintext format (JSON). This option may be accessed from the page menu (gear icon) in the top right. [Workspaces/Import] Workspace pages and tabs may be imported (in the same JSON format they export to). This provides a simple way to clone or share useful workspace configurations, either within a Cerb environment or externally. Pages can be imported from the create page popup; tabs can be imported on a specific workspace page from its '+' tab. [Workspaces/Usability] Workspace pages now display a configuration menu in the top right instead of a toolbar. This provides space for more options without adding visual clutter. The tab-related options (e.g. Edit Tab) are now hidden when the currently selected tab doesn't support those options (e.g. the built-in '+' tab). 6.4.1 [CHD-3370] [Custom Fieldsets/Code Cleanup] Deleting custom fieldsets is not possible. [CHD-3369] [Custom Fieldsets/Code Cleanup] Fixed an issue where custom fieldsets didn't link when applied to newly created tasks. The fields were set properly, but the fieldset itself didn't show up on peek or profile. [Platform/Automation] Updated the SQL automation scripts for 6.4 in the install/extras/automation/ directory. These allow the creation of a default database without having to run the installer. [Mail/Attachments] When displaying an HTML attachment in the browser, the UTF-8 character set will now be used. Many browsers were defaulting to Latin-1, which was showing corrupt characters for multibyte languages (like Chinese). [Workspaces/Wizard] Fixed an issue in the 'Help me create a page' wizard that was creating unusable workspaces. [CHD-3374] [Calendars/Usability] Reimplemented the floating calendar helper for picking dates in all date-based input fields (e.g. task due, ticket waiting until, custom fields). [Worklists/Aesthetics] The CSS styles for worklist hovering and selecting are now marked !important so they always override any other colorization. This is helpful when making VA behaviors that add new styles to worklists based on priority, etc. [CHD-3380] [Knowledgebase] Fixed an issue with knowledgebase navigation in workspace tabs. [Gravatar] If a message is from a worker then their gravatar is used rather than the reply-to address. [CHD-3381] [Mail/Reply/Custom Fields] Custom fields and fieldsets can now be set again while replying to tickets. Previously, this functionality set values for all custom fields regardless of whether or not they changed. This caused problems because workers that were changing the custom fields on a ticket during the course of a long reply would have their changes overwritten when the reply was sent. Now the worker sending a reply may choose which custom fields to set, and the values for everything else will remain unchanged. [CHD-3383] [Mail/Reply/Usability] When replying to a ticket, the "Would you like to move this conversation?" question now shows the current group and bucket in the default answer. For example: "No, leave it in the inbox of Support". Previously, workers had to open the picklist and scroll around to find where the conversation was currently located before they could decide if they wanted to move it -- this wasted the time spent moving a conversation only to find out that it's already at the destination. [Dates/Usability] Fixed a few rounding errors in relative dates displayed throughout the UI. For example, a relative time of '59 minutes 31 seconds' was being rounded up to '60 minutes', when it should display either '59 minutes' or '1 hour'. [CHD-3384] [Calendars/Recurring] Recurring calendar events may now specify a starting date to complement the ending date. [Less]

Release notes for Cerb 6.4 Cerb (6.4) is a major functionality update released on June 7, 2013. It contains over 118 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.4 [Dashboards/Widgets/Usability] ... [More] Dashboard widgets now display a single icon in the top right with a dropdown menu. This provides a place to add more options. Previously, every option was an icon, which limited the amount of space available to display the widget title. The new menu will be used to provide options like duplicating widgets or exporting their data. [Dashboards/Widgets/Gauges] Gauge widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Counters] Counter widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Charts] Chart widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Subtotals] Subtotal widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Scatterplots] Scatterplot widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Pie Chart] Pie chart widgets can now 'Export Data' to JSON or CSV. [Web-API/Usability] When using the 'expand' option in the Web-API, the extra records no longer contain extraneous fields like 'global timestamp' and the currently active worker. [Web-API/Authentication] Refactored the Web-API so that any code that checks for the 'active worker' may be used in API calls. The Web-API doesn't require sessions or cookies. Previously, the API implemented its own authentication, and the use of code that checked for a worker session would fail. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Pages. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Tabs. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Widgets. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::intClamp($n, $min, $max) for conveniently constraining a numeric value within a given range. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::strFormatJson($json) to format JSON in a human-friendly output. Nested properties are indented, and one key/value pair or array element is displayed per line. [Workspaces/Code Cleanup] Fixed an issue where worklist and subtotal widgets created an extra worker_view_model record in the database during rendering. There should be one entry per worklist-based series. [Workspaces/Widgets/Code Cleanup] Improved the way that widgets store worklist datasource information. Previously, Cerb stored a C4_AbstractViewModel object for each worklist datasource, serialized in PHP format, and base64 encoded in the widget properties. This was bloated and not very human friendly. It included a lot of information that could be reconstructed from worklist contexts. Worklist information is now stored by widgets in an easily readable JSON format, without any extraneous data, encoding, or serialization. At the same time, uniquely identifying information (like worklist IDs) are no longer used in widget properties, which paves the way for many new and highly anticipated features, like the ability to copy or share any widget. The format of existing widgets will be automatically converted during the upgrade process. [Workspaces/Widgets/Code Cleanup/Performance] Removed some unnecessary code that ran when configuring several workspace widgets: counters, gauges, subtotals, worklists. Several of these were derived from the original charting widget, and they emulated pulling a list of fields through Ajax every time the context (record type) of the worklist was changed in config. That information isn't used by any of these widgets, and its retrieval created a few needless calls to Cerb and the database. [Workspaces/Widget/Export] All workspace widgets now support the ability to export their configuration to a plaintext format (JSON). This option may be accessed by clicking the configuration menu in the top right of the widget, and selecting 'Export Widget'. Using this feature, widgets may be saved and transferred electronically; providing the beginnings of a community exchange for useful widgets. [Workspaces/Calendars] Migrated calendar workspace tabs to the new worklist datasource format. [Virtual Attendants/Worklists] Migrated Virtual Attendant 'Set List Variable' actions to the new worklist datasource format. This is a prerequisite for creating VA import/export functionality. [Workspaces/Dashboard/Widgets/Import] Dashboard widgets may now be imported from the 'Add Widget' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and clone widgets, and to share widgets between workers or Cerb installations. This was the last missing piece blocking an official repository of widgets from being created. [Workspaces/Dashboards/Widgets/Import] When importing dashboard widgets, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the widget before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a counter widget that reports on the number of overdue tasks owned by a specific worker can now prompt for which worker to use when being imported. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::jsonGetPointerFromPath() for making arbitrary changes at any depth to a JSON object by using an XPath-like path. This is used by the Virtual Attendant and Dashboard Widget import functionality to allow guided customizations prior to import. This helper method can be reused anywhere that similar functionality is required. [CHD-2530] [CHD-2688] [Virtual Attendants/Export] All Virtual Attendant behaviors now support the ability to export their decision trees to a plaintext format (JSON). This option may be accessed by clicking on the behavior and selecting 'Export Behavior' from the menu. Using this functionality, VA behaviors can now be duplicated, shared, or saved. The project can also maintain an official repository of useful VA behaviors that can be easily installed. [Virtual Attendants/Import] Virtual Attendant behaviors may now be imported from the 'Create Behavior' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and copy behaviors, and to share behaviors between groups, workers, or Cerb installations. For example, once setting up a complex auto-responder behavior for a group, it can be quickly copied to several other groups without having to tediously repeat the whole process of adding decisions, outcomes, and actions. This also makes it possible for the project to maintain an official repository of useful behaviors that can be easily imported into any Cerb instance. [Virtual Attendants/Import] When importing Virtual Attendant behavior, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the behavior before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a custom behavior that assigns tickets to a particular worker can now prompt for which worker to use when the behavior is imported in a new environment. [Debug/Virtual Attendants] The Virtual Attendant 'Export Behavior' option on the /debug page now uses the same JSON format as 'Export Behavior' does in the app. Previously, this used a special XML format which was only intended for human review but not importing. The new format allows imports by developers and QA to assist customers with troubleshooting. The advantage of using this option is that it exports all behaviors at once. It may also be used by administrators to review or make backups of all VA behaviors. [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/list.json' method to the RESTful Web-API. This retrieves a list of all workspace pages accessible by the current worker; owned by them, their groups, or roles. The 'expand' parameter includes additional information about each page's owner, tabs, widgets, or worklists. This is very useful for bringing workspace data into external interfaces (such as mobile apps). [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/123.json' method to the RESTful Web-API. This retrieves a specific page. The 'expand' parameter includes additional information about the page's owner, tabs, widgets, or worklists. [Web-API/Workspaces] Implemented a 'GET /workspaces/tabs/123.json' method to the RESTful Web-API. This retrieves a specific worklist tab. The 'expand' parameter includes additional information about widgets, widget data, or worklists. The data for all widgets on the tab may be retrieved in a single request, which makes it very easy to empower remote scripts and apps with the ability to monitor and report on Cerb dashboards. For example, a dashboard tab could summarize information about a series of servers in a datacenter, and a remote script could check those metrics against thresholds, whether they're counters, gauges, charts, etc. This is useful, since Cerb dashboards are very informative but they don't get a worker's attention if they aren't proactively monitored. [Web-API/Workspaces] Implemented a 'GET /workspaces/widgets/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace widget, and always includes the widgets raw data. This has all the same advantages for remote monitoring and reporting as pulling a workspace tab. [Web-API/Workspaces] Implemented a 'GET /workspaces/worklists/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace worklist. The response provides search results with support for sorting and paging. By setting up the desired filters on the Cerb dashboard, a remote API consumer doesn't have to concern itself with filtering results. For example, a remote app could display the 'Available tickets' worklist from an existing workspace, which may use a dozen filters to highlight the appropriate tickets. This not only saves the API consumer a lot of work in listing that information, but it also means that remote apps don't need to update every time the filters on the underlying worklist change. [CHD-2930] [CHD-3082] [Mail/POP3/Scheduler] A failing POP3/IMAP mailbox will no longer be auto-disabled after 5 consecutive failures. Instead, a delay of two minutes will be incurred for each consecutive failure up to a maximum delay of 30 minutes. This ensures that the mailbox will be retried within a reasonable amount of time. Previously, mailboxes could remain disabled over a weekend if no admins were available. Saving a mailbox in setup will reset the failure and delay counters. [Setup/Mail/POP3/Usability] Failing POP3 mailboxes are now marked with an icon in "Setup->Mail->POP3 Accounts". A message is also displayed when editing a failing mailbox that reads "Error! This mailbox has failed to check mail for (n) consecutive attempts". This should help admins spot potential issues more easily. [Setup/Mail/POP3/Aesthetics] Improved the process of deleting a mailbox from "Setup->Mail->POP3 Accounts". This is now more consistent with the rest of the app. Previously, you had to check a box at the bottom of the form to delete the mailbox. Nothing else in Cerb works like that. [Plugin Library/Setup] The 'Download updates' button in the Plugin Library will now automatically download any updates for all installed plugins. Previously, it just updated the version information but an admin had to update each plugin by clicking a button in the list. If a '.git' development directory exists in a plugin then it won't be automatically updated (as this would interfere with development). [Plugin Library/Upgrade/Platform] When upgrading from the /update page, Cerb will now attempt to download the latest version of all installed plugins from the Plugin Library. This should spare admins from having to manually update and re-enable all third-party plugins after an upgrade. [Custom Fieldsets] Custom fieldsets allow groups of related custom fields to be added to records in order to classify them. Previously, adding a new custom field to a type of record (e.g. tasks, tickets) would always display that field on every record. This led to a lot of clutter when custom fields were only used by a single group, worker, or Virtual Attendant behavior; and when a custom field was only related to a subset of records of the same type. With fieldsets, you can optionally add multiple sets of custom fields to a specific record. For example, an asset record could have a 'Car' fieldset added to it, with fields that describe mileage, color, make, model, VIN, etc. Another asset record could have a 'Computer' fieldset, with fields for CPU speed, RAM, serial #, etc. Both of these records would be assets, but they would be classified separately. These fields would not be mixed between the two records. It is still possible to have global custom fields for all records of the same type, as before; it's just no longer the only option. Fieldsets can be owned by roles, groups, or workers. Existing group-based custom fields will be converted to group-owned fieldsets during the migration. Fieldsets are managed in the peek popup and can be added using the 'Add Fieldset' button which displays a menu of available fieldsets. A fieldset can also be deleted by clicking the red X button that is displayed when hovering over any of its fields. [Groups/Custom Fields] The 'Custom Fields' tab on Group Setup now manages the custom fieldsets owned by the group, rather than individual global fields. [Custom Fields/Usability/Contexts] Contexts (record types) can now provide a hint that they implement custom fields for their records. This allows Cerb to only show custom field options for records that support them. Previously, the 'Custom Fields' page in Setup displayed many record types that had no way to display or edit such fields. [Profiles/Usability/Aesthetics] On the profile for every record type, the toolbar has been moved to the very top of the page. Since custom fieldsets are now displayed at the top of profiles, this helps the page flow better. [Custom Fieldsets/Subtotals] Since custom fieldsets have increased the length of many custom field names, the title of the subtotals sidebar on worklists will now be wrapped when necessary. [Custom Fieldsets/Bulk Update] Custom fieldsets and their fields may be set from the Bulk Update popup for any records that support them. [Knowledgebase/Bulk Update/Custom Fields] Custom fields may now be set on knowledgebase articles using Bulk Update. [Mail/Compose/Custom Fieldsets] Custom fieldsets may be set when composing mail. This solves a long-standing issue where desired custom fields couldn't easily be set when creating a ticket, and instead had to be set by subsequently editing the newly created record. Additionally, custom fields could only be set based on the group associated with the ticket. Now, all custom fieldsets are available when creating a ticket, irrespective of factors like the group. This also simplifies the compose popup by not displaying custom fields that aren't needed. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can now utilize custom fieldsets on conditions and actions. [Mail/Reply/Custom Fields] When replying to a ticket, custom fields will no longer be displayed at the bottom of the form. The main problem with the previous approach is that it led to overwriting any custom field changes that took place on the same record while a long reply was being drafted. This is because the form set the value of all fields, rather than only setting a few specific fields. This functionality can be reintroduced later in a better way. For now, custom fields may be set from the peek popup using the edit button after replying to a ticket. [Custom Fieldsets/Worklists/Subtotals] Subtotals and filters on worklists will now automatically adapt the available custom fields based on any active fieldset filters. For example, if there are 10 possible fieldsets for tickets, then you'll see a lot of custom fields for filtering or subtotaling a worklist. If the same worklist is filtered to a specific kind of fieldset, then only custom fields from that fieldset will be displayed when configuring the worklist. This helps progressively reduce clutter once the intentions of the worker are known to Cerb. [Platform/Update] When using the /update page to update Cerb, the lockfile being written to the temp directory was prefixed with 'c4' (from Cerb4). This has been changed to 'cerb' instead. [Choosers] The chooser popup is now given information about the record being displayed when it was opened, which allows it to customize itself appropriately. For example, a custom fieldset chooser should only show fieldsets for the given context (e.g. task, ticket). Other choosers can use this information to predict a worker's intentions and save them time. [Workspaces/Dashboards] Fixed an issue on dashboards where worklist-based counters and gauges didn't load values from custom fields that weren't in the filters. For example, a counter intended to SUM the value of a custom field may have displayed '0' even though several values existed. The reason for this is very technical, but has to do with how worklists intelligently use the most efficient way to load values based on how they are needed. When filtering, a slower LEFT JOIN is needed. For just displaying a value, a quick subquery is used without any joins. Counters and gauges always need to join values for aggregate functions. [Workspaces/Dashboards] Fixed an issue on worklist-based chart widgets where custom fields as axes may not display the proper values when they aren't used as filters on the underlying worklist. This had to do with how worklists interact with the database. The process is now more intuitive and custom fields can be selected without any other considerations. [Workspaces/Dashboards] Fixed an issue where scatterplots didn't display any plots if the dataset only had a single sample. [Platform] Removed the concept of ONDEMAND_MODE from the code, since this is handled better through a forked version of the project now. [Workspaces/Dashboards/Worklists/Usability] Worklists that are used as widgets on dashboards now label each field they display. Previously, a worker had to constantly refer to the horizontal order of the headings to figure out the vertical values being displayed for each row. The new approach uses a little more space but improves usability dramatically. [Platform/Plugin Development] The devblocks-dao.php script in /install/extras/sdk will now assist with creating the initial code and templates for contexts, profiles, and peeks. It also adds several useful virtual fields to the generated worklist: context links, watchers, and 'has fieldset'. Custom fields are enabled by default. The 'delete' option on peeks uses the two-step verification rather than the gaudy browser confirmation popup. [Calendars] Calendars are now distinct records that may be owned by workers, groups, or roles. Previously, events were directly owned by a worker and were collectively referred to as a calendar, although no record existed, and each worker could only have a single calendar. Any number of calendars may now be created, and owners may be responsible for several. For example, a group can define its collective working hours (e.g. for SLAs) as a group-owned calendar. The upgrade will create a calendar for each worker and assign their existing events to it. [Calendars/Events/Profiles] Fixed an issue where a calendar event profile page didn't refresh after the record was updated from the 'Edit' button. [Calendars] Calendars now have datasource extensions which are responsible for retrieving events for a given date range. Previously, events always had to be manually created. Now they can come from worklists, or synchronize from other apps and services. [Calendars/Platform/Plugins] Implemented DevblocksCalendarHelper::getCalendar($month, $year) which generates a calendar grid for use by multiple areas of functionality. [Calendars/Worklists] Calendars that display worklist-based events now provide the ability to create and edit records of that type. For example, a calendar that displays tasks by due date can be used to schedule new tasks or reschedule existing ones. This time sequence workflow is much easier to accomplish visually rather than with a worklist. [Devblocks/Platform/Code Cleanup] The timezone list returned by DevblocksPlatform::getDateService() is now provided by PHP's built-in timezone_identifiers_list() rather than from a hardcoded list. [Calendars] A calendar may now have multiple datasources. For example, a task calendar can display open tasks as one datasource in green, and completed tasks as a second datasource in gray. These colored events would be displayed on the same calendar in order to communicate more information at the same time. [Calendars] Calendars can toggle the ability of workers to create manual events in addition to those provided automatically by datasources. For example, on a calendar that displays task or invoice information, it is likely undesirable to allow manual events to be added to the calendar since all of the data is coming from worklists. [Calendars] Calendars can toggle the ability to allow automated synchronization from other datasources. On a calendar of manual events, synchronization may be disabled to simplify the calendar's configuration. This will hide the external datasource options. [Workspaces/Dashboards/Plugins] Dashboards now send a 'dashboard_heartbeat' event to all widgets every second. This can be used for timed behavior (clocks, etc) without having to implement timers for every widget. With timers for each widget, it is possible for two clocks on the same page to update at different intervals, which is visually distasteful and distracting. [Dashboards/Countdown] A new countdown widget is available on dashboards. You can use these widgets as gentle reminders of upcoming events. For example, on a development dashboard you can display a countdown to the next milestone (an iteration or release). On a sales dashboard, you can display the time left in the current period (quarter, year). [Dashboards/Clock] A new world clock widget is available on dashboards. The clocks support 12-hour or 24-hour display, and the closest timezone can be quickly selected from the list of major cities organized by continent and country. These widgets are particularly useful for coordinating with international team members or sales prospects. [Calendars/Events] Calendar event worklists can display their parent calendar as a column, and filter or subtotal by calendar. This is particularly useful in calendar event choosers. [Calendars/Workspaces] Existing calendar-based workspace tabs have been automatically converted to calendar records. These tabs now have access to all the functionality improvements related to calendars. An existing calendar may now be displayed on a workspace in a few clicks, and the same calendar may be displayed in multiple places and by multiple workers. [Calendars/Workspaces] The events from calendars on workspace tabs are now clickable. Previously, clicking on one of these events did nothing, which made it difficult to do anything useful with the calendar other than looking at it. Each event will open its peek popup depending on its type (e.g. tasks, tickets, events). [Calendars/Workspaces] Calendars displayed as workspace tabs may be edited directly from from the workspace by clicking on the gear icon. This removes the need to leave the workspace to modify the underlying calendar. [Calendars/Worklists] Calendars that use worklist-based datasources can now set availability (free/busy) and end dates for the events they generate. This means that in some situations, a datasource (like assigned tasks) may increase or reduce availability. [Calendars/Dashboards] Calendar widgets are now available on dashboards. These widgets offer a quick summary of a calendar without taking up much screen space. There’s a count of events occurring for each day, and the full list is displayed when hovering. You can also click each event to open its peek popup and modify it; and those changes will be immediately reflected on the calendar. This allows you to get more work done from your dashboard — rescheduling tasks, chasing overdue invoices, etc. You’ll also notice a small gear button at the top of the widget. If you have edit permission on the calendar, you can modify it directly from your dashboard as well. [Calendars/Availability] Rather than displaying a fixed calendar as before, worker profiles now display an Availability Calendar which takes the events from an existing calendar and converts them into availability windows. This is what a Virtual Attendant sees when it’s scheduling a task or looking for an available worker. Each worker can elect one of their calendars to determine their availability, which then becomes visible on their profile. This approach is particularly helpful in situations where a worker’s schedule may change frequently between various shifts. A calendar for each shift can be created, and when the schedule changes it’s a single click to activate a new calendar. To temporarily remove their availability entirely (e.g. vacation, leave of absence, paternity, sabbatical, code marathon), a worker can simply break the link between their availability and an existing calendar. They don’t need to modify or delete any of the existing events, which makes it much easier to resume working later on. [Calendars/Virtual Attendants] Virtual Attendants can set date-based behavior variables using calendars. This allows scheduling based on "work hours" to automatically skip nights, weekends, and holidays. [Calendars/Custom Fields] Added custom fields to calendar event records. [Calendars/Virtual Attendants] Virtual Attendants behaviors that use the 'Worker calendar' condition have been migrated to the new 'Worker availability' condition instead. This compares against each workers' preferred availability calendar. [Calendars/Workers/Worklist] Converted the use of the 'worker calendar' worklist filter to the new 'worker availability' filter. Rather than checking a single calendar, this now checks workers' preferred availability calendar. [Calendars/Events] When adding new records from a calendar event worklist, the current worker may choose to add the event to any of their writeable calendars. [Calendars/Events] In a calendar event worklist, the calendar field now links directly to its profile. [Calendars/Usability] Calendars that display worklist-based content now provide a way to create new records of those types. For example, a task-based calendar can be used to schedule new tasks, in addition to rearrange existing ones. This functionality is available in all the places where calendars are shown: calendar profiles, availability calendars, workspace tabs, and ashboard widgets. [Virtual Attendants/Calendars] Virtual Attendants can now set any date-based fields, custom fields, or behavior variables using calendars. [CHD-3356] [Virtual Attendants/Tasks] Fixed an issue where a date-based behavior variable couldn't be used to set the due date of the 'Create Task' action in Virtual Attendants. Text-based variables worked fine. [Virtual Attendants/Simulator] The Virtual Attendant simulator will now properly set custom fields using placeholders on the 'Create Task' and 'Create Ticket' actions. These values were actually set properly in behaviors, they just didn't translate in the simulator. [Calendars/Web-API] Implemented '/rest/calendars/123.json' in the Web API for retrieving calendar details. This can include a query parameter named 'expand' with the options 'weeks' (week and day data for drawing a calendar), 'events' (flat list of events during the calendar month), and 'weeks_events' (events grouped into days). Additionally, the arguments 'month' and 'year' may be provided to change the time period. [Calendars/Web-API] Implemented '/rest/calendars/list.json' in the Web API for retrieving a list of all accessible calendars for the current worker. [Calendars/Web-API] Implemented '/rest/calendars/search.json' in the Web API for searching calendars. [Calendars/Events/Recurring] Recurring calendar events are now virtualized. Rather than generating thousands of event records, recurring events are generated on-the-fly for any given date range. This cleans up a lot of redundant clutter in the database, and it also means that you can advance a calendar 10 years ahead and still see your recurring events, where previously such events were limited to displaying through the end of the current year (plus one month). The scheduler job for calendar scheduling is no longer needed and has been removed. Existing recurring events have been converted to the new format. [Calendars/Events/Recurring] The process of creating recurring events no longer relies on a rigid UI that forces a choice between daily, weekly, monthly, or yearly repetition. Recurring events may now be easily and quickly created using natural language, like "Weekdays", "Monday", "December 25", "15th", etc. Previously, it was not possible to set up recurring events like the US Holidays of Labor Day and Thanksgiving where they change every year. Now, recurring events can be created with patterns like "fourth Thursday in November" and "first Monday of every month". [Calendars/Events/Recurring] Recurring calendar events may now specify a timezone to be used when scheduling by relative times (e.g. 02:00 to 20:00). Previously, the timezone of the current worker was always assumed, but this made it difficult to deal with times that were intentionally in another timezone. Now a recurring event can be scheduled in London time while working in Los Angeles time. [Snippets/Worklists/Usability] Snippet worklists will no longer display the snippet preview for each row (no other record type did this, and it's available from peek). However, it will still be displayed on the snippet chooser where it remains useful. [Workspaces/Worklists/Usability] Worklists now determine the width of their columns without regard for the length of column headers. This was becoming a problem when long field names (particularly from custom fieldsets) were forcing columns to be much wider than their contents, which stole width from other columns that needed it more. For example, a column heading of "Organization SLA Is Expired" likely only needs to display values that are Yes/No. Under the new behavior, this column would now be narrower than its heading, and the extra space would be given to other columns. This functionality is also useful if you want to display many columns, because columns without any values in them won't waste screen space by displaying their full heading. [Virtual Attendants/UI/Worklists] Implemented a new Virtual Attendant event for '[UI] While displaying a worklist'. This allows behaviors that automate modifications to worklists in the browser using jQuery actions. These behaviors can target worklists by type (e.g. ticket, task) as well as unique identifier. This means modifications can be made to all worklists of a certain type anywhere in Cerb (widgets, workspaces, search, choosers), or such changes can be targeted to a specific instance of a worklist (e.g. just ticket choosers, or a single task worklist widget). These VA behaviors can be owned by Cerb, roles, or workers. A global behavior (e.g. role-owned) would be applied to displayed worklists for all workers. There are many use cases for this event: a date-based custom field can be colored red when overdue; a priority custom field can display colors for each level; relative dates (e.g. 2 hours) can be converted to absolute dates (e.g. June 3 2013 2pm); column headers can be relabeled; etc. [Worklists/Virtual Attendants] When a Virtual Attendant modifies a worklist, a robot icon is now displayed next to the worklist's title. Clicking this icon will display a list of the behaviors that were executed against the list (e.g. color rows by priority; color overdue due dates red; display dates as date+time). [Dates/Calendars/Usability] Implemented smart date input fields. Previously, you could only enter relative ("+2 hours") or absolute ("Jan 9 2020") dates into these fields. Now it's possible to schedule a relative date in 'working hours' using any calendar (for example, following an SLA schedule). This works whether you're scheduling a task due date, a ticket reopen, any custom field, or anything else. You can press ENTER in a date field to have any date text automatically converted into your current timezone. This allows workers to verify the final date before saving the record (where before, the relative date text was sent blindly to the server). [Dates/Calendars/Usability] As an additional convenience on smart date input fields, you can also convert dates and times from other timezones into your current timezone. For example, if you're in Los Angeles and you need to schedule a due date for 2pm tomorrow in London time, you can type "tomorrow 2pm Europe/London" into the date field and press ENTER. As a shortcut, you can also type "tomorrow 2pm Lon" and autocomplete the rest. [Tasks/Profile/Usability] The task profile page now makes it more obvious at a glance that a task is completed. In the properties, the status field will be colored green with a checkmark icon. [Orgs/Worklist] Fixed an issue where deleting an organization could result in a blank worklist. [CHD-3344] [Mail/Setup/Reply-To] When adding a new 'Reply-To' address, a 'delete' button will no longer be displayed. The option to delete should only be available when editing. [CHD-3311] [Virtual Attendants/Schedule Behavior] Virtual Attendants may now schedule the date for another behavior based on placeholders. [CHD-3353] [Virtual Attendants/Mail] Fixed the 'sender is worker' condition on 'New message on a group conversation' Virtual Attendant events when the ticket is created by a sender that is also a worker. [CHD-3338] [Virtual Attendants/Mail] Fixed an issue in Virtual Attendants where the setting of the 'Set Organization' action on the 'New message on a group conversation' was blank after re-editing. [CHD-3336] [Mail/Subtotals] Ticket worklists may now be subtotaled by the 'Last Action' field. The possible actions are New Ticket, Worker Replied, or Recipient Replied. [CHD-3335] [Tickets/Bulk/Usability] Using 'Bulk Update' on a ticket worklist will set the value of the 'Updated' field to the current time. This was requested as a way to identify tickets after the fact that were changed in the same batch. [CHD-3332] [Mail/Pile Sorter/Merge] When pile sorting a ticket worklist, the 'merge' action is now available for sub-piles. Previously if you pile sorted by sender, you could merge by domain but not by individual senders. [Calendars/Watchers] When a worker adds a new event or recurring event to a calendar, a notification will be sent to any watchers of that calendar. This makes it really easy for a worker to notice when someone adds an event to their calendar for them. [Mail/Reply/Keyboard] When replying to a ticket, the Ctrl+Shift+Enter keyboard shortcut will instantly send the message. [Mail/Reply/Keyboard] When replying to a ticket, three new shortcuts will automatically set the status of the ticket. Ctrl+Shift+O (open), Ctrl+Shift+W (waiting), Ctrl+Shift+C (closed). This saves extra mouse clicks, or the use of TAB to navigate down the page. [Mail/Reply/Dates/Keyboard] When replying to a message and entering a 'wait until' date, the Ctrl+Shift+Enter shortcut will convert the date and then send the message in a single keystroke. [Workspaces/Export] Workspace pages and tabs support the ability to export their configuration to a plaintext format (JSON). This option may be accessed from the page menu (gear icon) in the top right. [Workspaces/Import] Workspace pages and tabs may be imported (in the same JSON format they export to). This provides a simple way to clone or share useful workspace configurations, either within a Cerb environment or externally. Pages can be imported from the create page popup; tabs can be imported on a specific workspace page from its '+' tab. [Workspaces/Usability] Workspace pages now display a configuration menu in the top right instead of a toolbar. This provides space for more options without adding visual clutter. The tab-related options (e.g. Edit Tab) are now hidden when the currently selected tab doesn't support those options (e.g. the built-in '+' tab). 6.4.1 [CHD-3370] [Custom Fieldsets/Code Cleanup] Deleting custom fieldsets is not possible. [CHD-3369] [Custom Fieldsets/Code Cleanup] Fixed an issue where custom fieldsets didn't link when applied to newly created tasks. The fields were set properly, but the fieldset itself didn't show up on peek or profile. [Platform/Automation] Updated the SQL automation scripts for 6.4 in the install/extras/automation/ directory. These allow the creation of a default database without having to run the installer. [Mail/Attachments] When displaying an HTML attachment in the browser, the UTF-8 character set will now be used. Many browsers were defaulting to Latin-1, which was showing corrupt characters for multibyte languages (like Chinese). [Workspaces/Wizard] Fixed an issue in the 'Help me create a page' wizard that was creating unusable workspaces. [CHD-3374] [Calendars/Usability] Reimplemented the floating calendar helper for picking dates in all date-based input fields (e.g. task due, ticket waiting until, custom fields). [Worklists/Aesthetics] The CSS styles for worklist hovering and selecting are now marked !important so they always override any other colorization. This is helpful when making VA behaviors that add new styles to worklists based on priority, etc. [CHD-3380] [Knowledgebase] Fixed an issue with knowledgebase navigation in workspace tabs. [Gravatar] If a message is from a worker then their gravatar is used rather than the reply-to address. [CHD-3381] [Mail/Reply/Custom Fields] Custom fields and fieldsets can now be set again while replying to tickets. Previously, this functionality set values for all custom fields regardless of whether or not they changed. This caused problems because workers that were changing the custom fields on a ticket during the course of a long reply would have their changes overwritten when the reply was sent. Now the worker sending a reply may choose which custom fields to set, and the values for everything else will remain unchanged. [CHD-3383] [Mail/Reply/Usability] When replying to a ticket, the "Would you like to move this conversation?" question now shows the current group and bucket in the default answer. For example: "No, leave it in the inbox of Support". Previously, workers had to open the picklist and scroll around to find where the conversation was currently located before they could decide if they wanted to move it -- this wasted the time spent moving a conversation only to find out that it's already at the destination. [Dates/Usability] Fixed a few rounding errors in relative dates displayed throughout the UI. For example, a relative time of '59 minutes 31 seconds' was being rounded up to '60 minutes', when it should display either '59 minutes' or '1 hour'. [CHD-3384] [Calendars/Recurring] Recurring calendar events may now specify a starting date to complement the ending date. [Less]

Release notes for Cerb 6.4 Cerb (6.4) is a major functionality update released on June 7, 2013. It contains over 118 new features and usability tweaks from community feedback. See: http://wiki.cerbweb.com/6.4 [Dashboards/Widgets/Usability] ... [More] Dashboard widgets now display a single icon in the top right with a dropdown menu. This provides a place to add more options. Previously, every option was an icon, which limited the amount of space available to display the widget title. The new menu will be used to provide options like duplicating widgets or exporting their data. [Dashboards/Widgets/Gauges] Gauge widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Counters] Counter widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Charts] Chart widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Subtotals] Subtotal widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Scatterplots] Scatterplot widgets can now 'Export Data' to JSON or CSV. [Dashboards/Widgets/Pie Chart] Pie chart widgets can now 'Export Data' to JSON or CSV. [Web-API/Usability] When using the 'expand' option in the Web-API, the extra records no longer contain extraneous fields like 'global timestamp' and the currently active worker. [Web-API/Authentication] Refactored the Web-API so that any code that checks for the 'active worker' may be used in API calls. The Web-API doesn't require sessions or cookies. Previously, the API implemented its own authentication, and the use of code that checked for a worker session would fail. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Pages. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Tabs. [Workspaces/Plugins/Contexts] Implemented a context for Workspace Widgets. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::intClamp($n, $min, $max) for conveniently constraining a numeric value within a given range. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::strFormatJson($json) to format JSON in a human-friendly output. Nested properties are indented, and one key/value pair or array element is displayed per line. [Workspaces/Code Cleanup] Fixed an issue where worklist and subtotal widgets created an extra workerviewmodel record in the database during rendering. There should be one entry per worklist-based series. [Workspaces/Widgets/Code Cleanup] Improved the way that widgets store worklist datasource information. Previously, Cerb stored a C4_AbstractViewModel object for each worklist datasource, serialized in PHP format, and base64 encoded in the widget properties. This was bloated and not very human friendly. It included a lot of information that could be reconstructed from worklist contexts. Worklist information is now stored by widgets in an easily readable JSON format, without any extraneous data, encoding, or serialization. At the same time, uniquely identifying information (like worklist IDs) are no longer used in widget properties, which paves the way for many new and highly anticipated features, like the ability to copy or share any widget. The format of existing widgets will be automatically converted during the upgrade process. [Workspaces/Widgets/Code Cleanup/Performance] Removed some unnecessary code that ran when configuring several workspace widgets: counters, gauges, subtotals, worklists. Several of these were derived from the original charting widget, and they emulated pulling a list of fields through Ajax every time the context (record type) of the worklist was changed in config. That information isn't used by any of these widgets, and its retrieval created a few needless calls to Cerb and the database. [Workspaces/Widget/Export] All workspace widgets now support the ability to export their configuration to a plaintext format (JSON). This option may be accessed by clicking the configuration menu in the top right of the widget, and selecting 'Export Widget'. Using this feature, widgets may be saved and transferred electronically; providing the beginnings of a community exchange for useful widgets. [Workspaces/Calendars] Migrated calendar workspace tabs to the new worklist datasource format. [Virtual Attendants/Worklists] Migrated Virtual Attendant 'Set List Variable' actions to the new worklist datasource format. This is a prerequisite for creating VA import/export functionality. [Workspaces/Dashboard/Widgets/Import] Dashboard widgets may now be imported from the 'Add Widget' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and clone widgets, and to share widgets between workers or Cerb installations. This was the last missing piece blocking an official repository of widgets from being created. [Workspaces/Dashboards/Widgets/Import] When importing dashboard widgets, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the widget before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a counter widget that reports on the number of overdue tasks owned by a specific worker can now prompt for which worker to use when being imported. [Platform/Devblocks/Plugins] Implemented DevblocksPlatform::jsonGetPointerFromPath() for making arbitrary changes at any depth to a JSON object by using an XPath-like path. This is used by the Virtual Attendant and Dashboard Widget import functionality to allow guided customizations prior to import. This helper method can be reused anywhere that similar functionality is required. [CHD-2530] [CHD-2688] [Virtual Attendants/Export] All Virtual Attendant behaviors now support the ability to export their decision trees to a plaintext format (JSON). This option may be accessed by clicking on the behavior and selecting 'Export Behavior' from the menu. Using this functionality, VA behaviors can now be duplicated, shared, or saved. The project can also maintain an official repository of useful VA behaviors that can be easily installed. [Virtual Attendants/Import] Virtual Attendant behaviors may now be imported from the 'Create Behavior' popup (using the same JSON format that they export to). The popup now has tabs for 'Build' and 'Import'. This addresses several requests, including the ability to move and copy behaviors, and to share behaviors between groups, workers, or Cerb installations. For example, once setting up a complex auto-responder behavior for a group, it can be quickly copied to several other groups without having to tediously repeat the whole process of adding decisions, outcomes, and actions. This also makes it possible for the project to maintain an official repository of useful behaviors that can be easily imported into any Cerb instance. [Virtual Attendants/Import] When importing Virtual Attendant behavior, the import file may now specify any number of fields that should prompt the current worker for additional information. The answers to these prompts can customize the behavior before it is imported, rather than needing to instruct workers to make edits later. This also handles the situation where data like workers or groups are different between Cerb installs. For example, a custom behavior that assigns tickets to a particular worker can now prompt for which worker to use when the behavior is imported in a new environment. [Debug/Virtual Attendants] The Virtual Attendant 'Export Behavior' option on the /debug page now uses the same JSON format as 'Export Behavior' does in the app. Previously, this used a special XML format which was only intended for human review but not importing. The new format allows imports by developers and QA to assist customers with troubleshooting. The advantage of using this option is that it exports all behaviors at once. It may also be used by administrators to review or make backups of all VA behaviors. [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/list.json' method to the RESTful Web-API. This retrieves a list of all workspace pages accessible by the current worker; owned by them, their groups, or roles. The 'expand' parameter includes additional information about each page's owner, tabs, widgets, or worklists. This is very useful for bringing workspace data into external interfaces (such as mobile apps). [Web-API/Workspaces] Implemented a 'GET /workspaces/pages/123.json' method to the RESTful Web-API. This retrieves a specific page. The 'expand' parameter includes additional information about the page's owner, tabs, widgets, or worklists. [Web-API/Workspaces] Implemented a 'GET /workspaces/tabs/123.json' method to the RESTful Web-API. This retrieves a specific worklist tab. The 'expand' parameter includes additional information about widgets, widget data, or worklists. The data for all widgets on the tab may be retrieved in a single request, which makes it very easy to empower remote scripts and apps with the ability to monitor and report on Cerb dashboards. For example, a dashboard tab could summarize information about a series of servers in a datacenter, and a remote script could check those metrics against thresholds, whether they're counters, gauges, charts, etc. This is useful, since Cerb dashboards are very informative but they don't get a worker's attention if they aren't proactively monitored. [Web-API/Workspaces] Implemented a 'GET /workspaces/widgets/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace widget, and always includes the widgets raw data. This has all the same advantages for remote monitoring and reporting as pulling a workspace tab. [Web-API/Workspaces] Implemented a 'GET /workspaces/worklists/123.json' method to the RESTful Web-API. This retrieves information about a specific workspace worklist. The response provides search results with support for sorting and paging. By setting up the desired filters on the Cerb dashboard, a remote API consumer doesn't have to concern itself with filtering results. For example, a remote app could display the 'Available tickets' worklist from an existing workspace, which may use a dozen filters to highlight the appropriate tickets. This not only saves the API consumer a lot of work in listing that information, but it also means that remote apps don't need to update every time the filters on the underlying worklist change. [CHD-2930] [CHD-3082] [Mail/POP3/Scheduler] A failing POP3/IMAP mailbox will no longer be auto-disabled after 5 consecutive failures. Instead, a delay of two minutes will be incurred for each consecutive failure up to a maximum delay of 30 minutes. This ensures that the mailbox will be retried within a reasonable amount of time. Previously, mailboxes could remain disabled over a weekend if no admins were available. Saving a mailbox in setup will reset the failure and delay counters. [Setup/Mail/POP3/Usability] Failing POP3 mailboxes are now marked with an icon in "Setup->Mail->POP3 Accounts". A message is also displayed when editing a failing mailbox that reads "Error! This mailbox has failed to check mail for (n) consecutive attempts". This should help admins spot potential issues more easily. [Setup/Mail/POP3/Aesthetics] Improved the process of deleting a mailbox from "Setup->Mail->POP3 Accounts". This is now more consistent with the rest of the app. Previously, you had to check a box at the bottom of the form to delete the mailbox. Nothing else in Cerb works like that. [Plugin Library/Setup] The 'Download updates' button in the Plugin Library will now automatically download any updates for all installed plugins. Previously, it just updated the version information but an admin had to update each plugin by clicking a button in the list. If a '.git' development directory exists in a plugin then it won't be automatically updated (as this would interfere with development). [Plugin Library/Upgrade/Platform] When upgrading from the /update page, Cerb will now attempt to download the latest version of all installed plugins from the Plugin Library. This should spare admins from having to manually update and re-enable all third-party plugins after an upgrade. [Custom Fieldsets] Custom fieldsets allow groups of related custom fields to be added to records in order to classify them. Previously, adding a new custom field to a type of record (e.g. tasks, tickets) would always display that field on every record. This led to a lot of clutter when custom fields were only used by a single group, worker, or Virtual Attendant behavior; and when a custom field was only related to a subset of records of the same type. With fieldsets, you can optionally add multiple sets of custom fields to a specific record. For example, an asset record could have a 'Car' fieldset added to it, with fields that describe mileage, color, make, model, VIN, etc. Another asset record could have a 'Computer' fieldset, with fields for CPU speed, RAM, serial #, etc. Both of these records would be assets, but they would be classified separately. These fields would not be mixed between the two records. It is still possible to have global custom fields for all records of the same type, as before; it's just no longer the only option. Fieldsets can be owned by roles, groups, or workers. Existing group-based custom fields will be converted to group-owned fieldsets during the migration. Fieldsets are managed in the peek popup and can be added using the 'Add Fieldset' button which displays a menu of available fieldsets. A fieldset can also be deleted by clicking the red X button that is displayed when hovering over any of its fields. [Groups/Custom Fields] The 'Custom Fields' tab on Group Setup now manages the custom fieldsets owned by the group, rather than individual global fields. [Custom Fields/Usability/Contexts] Contexts (record types) can now provide a hint that they implement custom fields for their records. This allows Cerb to only show custom field options for records that support them. Previously, the 'Custom Fields' page in Setup displayed many record types that had no way to display or edit such fields. [Profiles/Usability/Aesthetics] On the profile for every record type, the toolbar has been moved to the very top of the page. Since custom fieldsets are now displayed at the top of profiles, this helps the page flow better. [Custom Fieldsets/Subtotals] Since custom fieldsets have increased the length of many custom field names, the title of the subtotals sidebar on worklists will now be wrapped when necessary. [Custom Fieldsets/Bulk Update] Custom fieldsets and their fields may be set from the Bulk Update popup for any records that support them. [Knowledgebase/Bulk Update/Custom Fields] Custom fields may now be set on knowledgebase articles using Bulk Update. [Mail/Compose/Custom Fieldsets] Custom fieldsets may be set when composing mail. This solves a long-standing issue where desired custom fields couldn't easily be set when creating a ticket, and instead had to be set by subsequently editing the newly created record. Additionally, custom fields could only be set based on the group associated with the ticket. Now, all custom fieldsets are available when creating a ticket, irrespective of factors like the group. This also simplifies the compose popup by not displaying custom fields that aren't needed. [Virtual Attendants/Custom Fieldsets] Virtual Attendants can now utilize custom fieldsets on conditions and actions. [Mail/Reply/Custom Fields] When replying to a ticket, custom fields will no longer be displayed at the bottom of the form. The main problem with the previous approach is that it led to overwriting any custom field changes that took place on the same record while a long reply was being drafted. This is because the form set the value of all fields, rather than only setting a few specific fields. This functionality can be reintroduced later in a better way. For now, custom fields may be set from the peek popup using the edit button after replying to a ticket. [Custom Fieldsets/Worklists/Subtotals] Subtotals and filters on worklists will now automatically adapt the available custom fields based on any active fieldset filters. For example, if there are 10 possible fieldsets for tickets, then you'll see a lot of custom fields for filtering or subtotaling a worklist. If the same worklist is filtered to a specific kind of fieldset, then only custom fields from that fieldset will be displayed when configuring the worklist. This helps progressively reduce clutter once the intentions of the worker are known to Cerb. [Platform/Update] When using the /update page to update Cerb, the lockfile being written to the temp directory was prefixed with 'c4' (from Cerb4). This has been changed to 'cerb' instead. [Choosers] The chooser popup is now given information about the record being displayed when it was opened, which allows it to customize itself appropriately. For example, a custom fieldset chooser should only show fieldsets for the given context (e.g. task, ticket). Other choosers can use this information to predict a worker's intentions and save them time. [Workspaces/Dashboards] Fixed an issue on dashboards where worklist-based counters and gauges didn't load values from custom fields that weren't in the filters. For example, a counter intended to SUM the value of a custom field may have displayed '0' even though several values existed. The reason for this is very technical, but has to do with how worklists intelligently use the most efficient way to load values based on how they are needed. When filtering, a slower LEFT JOIN is needed. For just displaying a value, a quick subquery is used without any joins. Counters and gauges always need to join values for aggregate functions. [Workspaces/Dashboards] Fixed an issue on worklist-based chart widgets where custom fields as axes may not display the proper values when they aren't used as filters on the underlying worklist. This had to do with how worklists interact with the database. The process is now more intuitive and custom fields can be selected without any other considerations. [Workspaces/Dashboards] Fixed an issue where scatterplots didn't display any plots if the dataset only had a single sample. [Platform] Removed the concept of ONDEMAND_MODE from the code, since this is handled better through a forked version of the project now. [Workspaces/Dashboards/Worklists/Usability] Worklists that are used as widgets on dashboards now label each field they display. Previously, a worker had to constantly refer to the horizontal order of the headings to figure out the vertical values being displayed for each row. The new approach uses a little more space but improves usability dramatically. [Platform/Plugin Development] The devblocks-dao.php script in /install/extras/sdk will now assist with creating the initial code and templates for contexts, profiles, and peeks. It also adds several useful virtual fields to the generated worklist: context links, watchers, and 'has fieldset'. Custom fields are enabled by default. The 'delete' option on peeks uses the two-step verification rather than the gaudy browser confirmation popup. [Calendars] Calendars are now distinct records that may be owned by workers, groups, or roles. Previously, events were directly owned by a worker and were collectively referred to as a calendar, although no record existed, and each worker could only have a single calendar. Any number of calendars may now be created, and owners may be responsible for several. For example, a group can define its collective working hours (e.g. for SLAs) as a group-owned calendar. The upgrade will create a calendar for each worker and assign their existing events to it. [Calendars/Events/Profiles] Fixed an issue where a calendar event profile page didn't refresh after the record was updated from the 'Edit' button. [Calendars] Calendars now have datasource extensions which are responsible for retrieving events for a given date range. Previously, events always had to be manually created. Now they can come from worklists, or synchronize from other apps and services. [Calendars/Platform/Plugins] Implemented DevblocksCalendarHelper::getCalendar($month, $year) which generates a calendar grid for use by multiple areas of functionality. [Calendars/Worklists] Calendars that display worklist-based events now provide the ability to create and edit records of that type. For example, a calendar that displays tasks by due date can be used to schedule new tasks or reschedule existing ones. This time sequence workflow is much easier to accomplish visually rather than with a worklist. [Devblocks/Platform/Code Cleanup] The timezone list returned by DevblocksPlatform::getDateService() is now provided by PHP's built-in timezoneidentifierslist() rather than from a hardcoded list. [Calendars] A calendar may now have multiple datasources. For example, a task calendar can display open tasks as one datasource in green, and completed tasks as a second datasource in gray. These colored events would be displayed on the same calendar in order to communicate more information at the same time. [Calendars] Calendars can toggle the ability of workers to create manual events in addition to those provided automatically by datasources. For example, on a calendar that displays task or invoice information, it is likely undesirable to allow manual events to be added to the calendar since all of the data is coming from worklists. [Calendars] Calendars can toggle the ability to allow automated synchronization from other datasources. On a calendar of manual events, synchronization may be disabled to simplify the calendar's configuration. This will hide the external datasource options. [Workspaces/Dashboards/Plugins] Dashboards now send a 'dashboard_heartbeat' event to all widgets every second. This can be used for timed behavior (clocks, etc) without having to implement timers for every widget. With timers for each widget, it is possible for two clocks on the same page to update at different intervals, which is visually distasteful and distracting. [Dashboards/Countdown] A new countdown widget is available on dashboards. You can use these widgets as gentle reminders of upcoming events. For example, on a development dashboard you can display a countdown to the next milestone (an iteration or release). On a sales dashboard, you can display the time left in the current period (quarter, year). [Dashboards/Clock] A new world clock widget is available on dashboards. The clocks support 12-hour or 24-hour display, and the closest timezone can be quickly selected from the list of major cities organized by continent and country. These widgets are particularly useful for coordinating with international team members or sales prospects. [Calendars/Events] Calendar event worklists can display their parent calendar as a column, and filter or subtotal by calendar. This is particularly useful in calendar event choosers. [Calendars/Workspaces] Existing calendar-based workspace tabs have been automatically converted to calendar records. These tabs now have access to all the functionality improvements related to calendars. An existing calendar may now be displayed on a workspace in a few clicks, and the same calendar may be displayed in multiple places and by multiple workers. [Calendars/Workspaces] The events from calendars on workspace tabs are now clickable. Previously, clicking on one of these events did nothing, which made it difficult to do anything useful with the calendar other than looking at it. Each event will open its peek popup depending on its type (e.g. tasks, tickets, events). [Calendars/Workspaces] Calendars displayed as workspace tabs may be edited directly from from the workspace by clicking on the gear icon. This removes the need to leave the workspace to modify the underlying calendar. [Calendars/Worklists] Calendars that use worklist-based datasources can now set availability (free/busy) and end dates for the events they generate. This means that in some situations, a datasource (like assigned tasks) may increase or reduce availability. [Calendars/Dashboards] Calendar widgets are now available on dashboards. These widgets offer a quick summary of a calendar without taking up much screen space. There’s a count of events occurring for each day, and the full list is displayed when hovering. You can also click each event to open its peek popup and modify it; and those changes will be immediately reflected on the calendar. This allows you to get more work done from your dashboard — rescheduling tasks, chasing overdue invoices, etc. You’ll also notice a small gear button at the top of the widget. If you have edit permission on the calendar, you can modify it directly from your dashboard as well. [Calendars/Availability] Rather than displaying a fixed calendar as before, worker profiles now display an Availability Calendar which takes the events from an existing calendar and converts them into availability windows. This is what a Virtual Attendant sees when it’s scheduling a task or looking for an available worker. Each worker can elect one of their calendars to determine their availability, which then becomes visible on their profile. This approach is particularly helpful in situations where a worker’s schedule may change frequently between various shifts. A calendar for each shift can be created, and when the schedule changes it’s a single click to activate a new calendar. To temporarily remove their availability entirely (e.g. vacation, leave of absence, paternity, sabbatical, code marathon), a worker can simply break the link between their availability and an existing calendar. They don’t need to modify or delete any of the existing events, which makes it much easier to resume working later on. [Calendars/Virtual Attendants] Virtual Attendants can set date-based behavior variables using calendars. This allows scheduling based on "work hours" to automatically skip nights, weekends, and holidays. [Calendars/Custom Fields] Added custom fields to calendar event records. [Calendars/Virtual Attendants] Virtual Attendants behaviors that use the 'Worker calendar' condition have been migrated to the new 'Worker availability' condition instead. This compares against each workers' preferred availability calendar. [Calendars/Workers/Worklist] Converted the use of the 'worker calendar' worklist filter to the new 'worker availability' filter. Rather than checking a single calendar, this now checks workers' preferred availability calendar. [Calendars/Events] When adding new records from a calendar event worklist, the current worker may choose to add the event to any of their writeable calendars. [Calendars/Events] In a calendar event worklist, the calendar field now links directly to its profile. [Calendars/Usability] Calendars that display worklist-based content now provide a way to create new records of those types. For example, a task-based calendar can be used to schedule new tasks, in addition to rearrange existing ones. This functionality is available in all the places where calendars are shown: calendar profiles, availability calendars, workspace tabs, and ashboard widgets. [Virtual Attendants/Calendars] Virtual Attendants can now set any date-based fields, custom fields, or behavior variables using calendars. [CHD-3356] [Virtual Attendants/Tasks] Fixed an issue where a date-based behavior variable couldn't be used to set the due date of the 'Create Task' action in Virtual Attendants. Text-based variables worked fine. [Virtual Attendants/Simulator] The Virtual Attendant simulator will now properly set custom fields using placeholders on the 'Create Task' and 'Create Ticket' actions. These values were actually set properly in behaviors, they just didn't translate in the simulator. [Calendars/Web-API] Implemented '/rest/calendars/123.json' in the Web API for retrieving calendar details. This can include a query parameter named 'expand' with the options 'weeks' (week and day data for drawing a calendar), 'events' (flat list of events during the calendar month), and 'weeks_events' (events grouped into days). Additionally, the arguments 'month' and 'year' may be provided to change the time period. [Calendars/Web-API] Implemented '/rest/calendars/list.json' in the Web API for retrieving a list of all accessible calendars for the current worker. [Calendars/Web-API] Implemented '/rest/calendars/search.json' in the Web API for searching calendars. [Calendars/Events/Recurring] Recurring calendar events are now virtualized. Rather than generating thousands of event records, recurring events are generated on-the-fly for any given date range. This cleans up a lot of redundant clutter in the database, and it also means that you can advance a calendar 10 years ahead and still see your recurring events, where previously such events were limited to displaying through the end of the current year (plus one month). The scheduler job for calendar scheduling is no longer needed and has been removed. Existing recurring events have been converted to the new format. [Calendars/Events/Recurring] The process of creating recurring events no longer relies on a rigid UI that forces a choice between daily, weekly, monthly, or yearly repetition. Recurring events may now be easily and quickly created using natural language, like "Weekdays", "Monday", "December 25", "15th", etc. Previously, it was not possible to set up recurring events like the US Holidays of Labor Day and Thanksgiving where they change every year. Now, recurring events can be created with patterns like "fourth Thursday in November" and "first Monday of every month". [Calendars/Events/Recurring] Recurring calendar events may now specify a timezone to be used when scheduling by relative times (e.g. 02:00 to 20:00). Previously, the timezone of the current worker was always assumed, but this made it difficult to deal with times that were intentionally in another timezone. Now a recurring event can be scheduled in London time while working in Los Angeles time. [Snippets/Worklists/Usability] Snippet worklists will no longer display the snippet preview for each row (no other record type did this, and it's available from peek). However, it will still be displayed on the snippet chooser where it remains useful. [Workspaces/Worklists/Usability] Worklists now determine the width of their columns without regard for the length of column headers. This was becoming a problem when long field names (particularly from custom fieldsets) were forcing columns to be much wider than their contents, which stole width from other columns that needed it more. For example, a column heading of "Organization SLA Is Expired" likely only needs to display values that are Yes/No. Under the new behavior, this column would now be narrower than its heading, and the extra space would be given to other columns. This functionality is also useful if you want to display many columns, because columns without any values in them won't waste screen space by displaying their full heading. [Virtual Attendants/UI/Worklists] Implemented a new Virtual Attendant event for '[UI] While displaying a worklist'. This allows behaviors that automate modifications to worklists in the browser using jQuery actions. These behaviors can target worklists by type (e.g. ticket, task) as well as unique identifier. This means modifications can be made to all worklists of a certain type anywhere in Cerb (widgets, workspaces, search, choosers), or such changes can be targeted to a specific instance of a worklist (e.g. just ticket choosers, or a single task worklist widget). These VA behaviors can be owned by Cerb, roles, or workers. A global behavior (e.g. role-owned) would be applied to displayed worklists for all workers. There are many use cases for this event: a date-based custom field can be colored red when overdue; a priority custom field can display colors for each level; relative dates (e.g. 2 hours) can be converted to absolute dates (e.g. June 3 2013 2pm); column headers can be relabeled; etc. [Worklists/Virtual Attendants] When a Virtual Attendant modifies a worklist, a robot icon is now displayed next to the worklist's title. Clicking this icon will display a list of the behaviors that were executed against the list (e.g. color rows by priority; color overdue due dates red; display dates as date+time). [Dates/Calendars/Usability] Implemented smart date input fields. Previously, you could only enter relative ("+2 hours") or absolute ("Jan 9 2020") dates into these fields. Now it's possible to schedule a relative date in 'working hours' using any calendar (for example, following an SLA schedule). This works whether you're scheduling a task due date, a ticket reopen, any custom field, or anything else. You can press ENTER in a date field to have any date text automatically converted into your current timezone. This allows workers to verify the final date before saving the record (where before, the relative date text was sent blindly to the server). [Dates/Calendars/Usability] As an additional convenience on smart date input fields, you can also convert dates and times from other timezones into your current timezone. For example, if you're in Los Angeles and you need to schedule a due date for 2pm tomorrow in London time, you can type "tomorrow 2pm Europe/London" into the date field and press ENTER. As a shortcut, you can also type "tomorrow 2pm Lon" and autocomplete the rest. [Tasks/Profile/Usability] The task profile page now makes it more obvious at a glance that a task is completed. In the properties, the status field will be colored green with a checkmark icon. [Orgs/Worklist] Fixed an issue where deleting an organization could result in a blank worklist. [CHD-3344] [Mail/Setup/Reply-To] When adding a new 'Reply-To' address, a 'delete' button will no longer be displayed. The option to delete should only be available when editing. [CHD-3311] [Virtual Attendants/Schedule Behavior] Virtual Attendants may now schedule the date for another behavior based on placeholders. [CHD-3353] [Virtual Attendants/Mail] Fixed the 'sender is worker' condition on 'New message on a group conversation' Virtual Attendant events when the ticket is created by a sender that is also a worker. [CHD-3338] [Virtual Attendants/Mail] Fixed an issue in Virtual Attendants where the setting of the 'Set Organization' action on the 'New message on a group conversation' was blank after re-editing. [CHD-3336] [Mail/Subtotals] Ticket worklists may now be subtotaled by the 'Last Action' field. The possible actions are New Ticket, Worker Replied, or Recipient Replied. [CHD-3335] [Tickets/Bulk/Usability] Using 'Bulk Update' on a ticket worklist will set the value of the 'Updated' field to the current time. This was requested as a way to identify tickets after the fact that were changed in the same batch. [CHD-3332] [Mail/Pile Sorter/Merge] When pile sorting a ticket worklist, the 'merge' action is now available for sub-piles. Previously if you pile sorted by sender, you could merge by domain but not by individual senders. [Calendars/Watchers] When a worker adds a new event or recurring event to a calendar, a notification will be sent to any watchers of that calendar. This makes it really easy for a worker to notice when someone adds an event to their calendar for them. [Mail/Reply/Keyboard] When replying to a ticket, the Ctrl+Shift+Enter keyboard shortcut will instantly send the message. [Mail/Reply/Keyboard] When replying to a ticket, three new shortcuts will automatically set the status of the ticket. Ctrl+Shift+O (open), Ctrl+Shift+W (waiting), Ctrl+Shift+C (closed). This saves extra mouse clicks, or the use of TAB to navigate down the page. [Mail/Reply/Dates/Keyboard] When replying to a message and entering a 'wait until' date, the Ctrl+Shift+Enter shortcut will convert the date and then send the message in a single keystroke. [Workspaces/Export] Workspace pages and tabs support the ability to export their configuration to a plaintext format (JSON). This option may be accessed from the page menu (gear icon) in the top right. [Workspaces/Import] Workspace pages and tabs may be imported (in the same JSON format they export to). This provides a simple way to clone or share useful workspace configurations, either within a Cerb environment or externally. Pages can be imported from the create page popup; tabs can be imported on a specific workspace page from its '+' tab. [Workspaces/Usability] Workspace pages now display a configuration menu in the top right instead of a toolbar. This provides space for more options without adding visual clutter. The tab-related options (e.g. Edit Tab) are now hidden when the currently selected tab doesn't support those options (e.g. the built-in '+' tab). 6.4.1 [CHD-3370] [Custom Fieldsets/Code Cleanup] Deleting custom fieldsets is not possible. [CHD-3369] [Custom Fieldsets/Code Cleanup] Fixed an issue where custom fieldsets didn't link when applied to newly created tasks. The fields were set properly, but the fieldset itself didn't show up on peek or profile. [Platform/Automation] Updated the SQL automation scripts for 6.4 in the install/extras/automation/ directory. These allow the creation of a default database without having to run the installer. [Mail/Attachments] When displaying an HTML attachment in the browser, the UTF-8 character set will now be used. Many browsers were defaulting to Latin-1, which was showing corrupt characters for multibyte languages (like Chinese). [Workspaces/Wizard] Fixed an issue in the 'Help me create a page' wizard that was creating unusable workspaces. [CHD-3374] [Calendars/Usability] Reimplemented the floating calendar helper for picking dates in all date-based input fields (e.g. task due, ticket waiting until, custom fields). [Worklists/Aesthetics] The CSS styles for worklist hovering and selecting are now marked !important so they always override any other colorization. This is helpful when making VA behaviors that add new styles to worklists based on priority, etc. [CHD-3380] [Knowledgebase] Fixed an issue with knowledgebase navigation in workspace tabs. [Gravatar] If a message is from a worker then their gravatar is used rather than the reply-to address. [CHD-3381] [Mail/Reply/Custom Fields] Custom fields and fieldsets can now be set again while replying to tickets. Previously, this functionality set values for all custom fields regardless of whether or not they changed. This caused problems because workers that were changing the custom fields on a ticket during the course of a long reply would have their changes overwritten when the reply was sent. Now the worker sending a reply may choose which custom fields to set, and the values for everything else will remain unchanged. [CHD-3383] [Mail/Reply/Usability] When replying to a ticket, the "Would you like to move this conversation?" question now shows the current group and bucket in the default answer. For example: "No, leave it in the inbox of Support". Previously, workers had to open the picklist and scroll around to find where the conversation was currently located before they could decide if they wanted to move it -- this wasted the time spent moving a conversation only to find out that it's already at the destination. [Dates/Usability] Fixed a few rounding errors in relative dates displayed throughout the UI. For example, a relative time of '59 minutes 31 seconds' was being rounded up to '60 minutes', when it should display either '59 minutes' or '1 hour'. [CHD-3384] [Calendars/Recurring] Recurring calendar events may now specify a starting date to complement the ending date. [Less]