Most Popular
Recently Added
Recently Updated

6.7 Changelog

Release notes for Cerb 6.7

Cerb (6.7) is a major functionality update released on April 22, 2014. It contains over 106 new features and usability tweaks from community feedback.

See: http://wiki.cerbweb.com/6.7

  • [Broadcast] Fixed a bug that prevented the 'Test' button from working on Broadcast functionality.

  • [Mail/Compose] [CHD-2734] Fixed another issue with the Send Mail form where workers who used it for the first time (i.e. prior to having a default preference) were unable to send mail if by chance they did not need to change the value of the 'From:' drop-down. If the drop-down was changed then everything worked as expected.

  • [Workspaces/Dashboards] Dashboards can now be configured to display widgets in one, two, three, or four columns. Extra columns are added to the right without rearranging existing widgets. When removing columns from a dashboard, widgets are automatically and evenly redistributed, and can be dragged into a desired order from there. By using one or two columns, more space is available for detailed charts. Four column dashboards can display many compact widgets on a single page without scrolling, and make better use of larger displays.

  • [Workspaces/Dashboards/Performance] The content on dashboard widgets is now cached for 60 seconds, which can dramatically improve performance with many concurrent workers. Manually clicking the reload button on a widget will update it with the latest data. When a dashboard is first displayed, any cached content is displayed immediately when the tab first draws. Any widgets with an expired cache are then displayed with a "spinner" image and fetched in sequence through an Ajax pipeline. This process is much more responsive than the previous behavior of waiting until all the widgets have loaded before displaying anything (and leaving workers staring at a mostly blank screen wondering if something is broken). It's also more memory efficient.

  • [Workspaces/Dashboards/Usability] When a workspace dashboard tab is blank, a helper message is now displayed with instructions on how to modify the number of columns and add new widgets.

  • [Workspaces/Usability] When a new tab is added to a workspace it is now automatically selected. Previously the new tab was highlighted but it still had to be clicked, which was only helpful in a situation where a worker intended to add several tabs at once before modifying any of them. This made the most common use case slightly more difficult.

  • [CHD-3065] [Workspaces/Worklists/Usability] Worklists are now loaded in order on workspace tabs using an efficient Ajax queue. Previously this process attempted to only load worklists that were visible in the scrolled browser window, but this is no longer necessary with the workspace improvements in 6.x. The loading worklists have a more modern style and an animated "spinner" image.

  • [Workspaces/Dashboards/Widgets/Performance] The caching on dashboards can now be configured per-widget. By setting a higher cache TTL (time-to-live) on infrequently used or changed data, page generation performance is improved. The default cache lifetime is set to 60 seconds on every widget during the migration. Refreshing a widget manually automatically uses the latest data and updates the cache.

  • [CHD-3172] [Virtual Attendants/Mail] The 'initial message' and 'latest message' placeholders are now available in all message-based Virtual Attendant behaviors.

  • [Virtual Attendants/Simulator/Usability] The Virtual Attendant simulator now only makes conditions editable if they are used by the behavior being tested. For instance, an auto-reply behavior that uses the conditions 'message is new' and 'message is outgoing' will now only show those two values in the simulator, which drastically improves usability. Previously, the values of every possible condition were shown (potentially hundreds) even though most of them weren't useful for testing the current behavior.

  • [Platform/Dependencies/Twig] Updated the Twig template engine from 1.8.2 (2012-05-29) to 1.15.1 (2014-02-13).

  • [Search/Performance] Full-text search results will now be retrieved as matching IDs before any other filters are applied. In most cases, this is much faster and more efficient than trying to do everything at once. This improvement makes it possible to consistently cache the results of full-text searches, even when other filters on the same worklist change. Previously, each variation of filters would require a different cache, and this could quickly overwhelm the default query cache settings in MySQL. Additionally, full-text results are now sorted by relevancy (best fit for the given search terms) and the top 250 matches are returned. Previously, relevancy wasn't considered at all, and any number of results were returned (even hundreds of thousands), which was very inefficient. The scope can be narrowed by searching for more specific terms. This "pre-fetch" step for full-text searching also makes it very easy for Cerb to integrate with other search engines like Sphinx, Solr, Elasticsearch, etc.

  • [Search/Platform/Plugins] Cerb's built-in MySQL full-text search engine now supports attributes (textual or numeric). This makes it possible to segment the indexed content. For instance, the comment content index now has a 'context' attribute, which can restrict text matches to only comments of a specific type (ticket, task, opp, etc). This was a necessary change due to the other improvements in full-text searching, since it would have been possible for search text to match 250 comment records without any of them belonging to the appropriate type of record. Each search schema can define its own attributes, and these will be automatically added when a new fulltext_* table is created. Most specialized search engines (like Sphinx) already have the capability to track attributes, and this change will make it easier for Cerb to seamlessly integrate with them.

  • [Placeholders/Snippets/Virtual Attendants] Added a 'secs_pretty' filter to placeholders. This displays a number of elapsed seconds as a human readable label like '2 hours, 5 mins'.

  • [Search/Platform/Devblocks] New search engine platforms can be added to Devblocks as extensions. The default implementation remains MySQL Fulltext, but plugins can implement native support for Apache Solr, Sphinx, Elasticsearch, Cloudsearch, etc.

  • [Search/Quick/Usability] Search engines can now provide their own quick search examples on a per-field basis. These are shown when a worker selects a fulltext field from the quick search dropdown. For instance, MySQL Fulltext and Sphinx have different search syntaxes. If a search index is moved to Sphinx, workers will be given the appropriate search tips. The quick search examples can also include custom examples per-index, so any additional fields indexed in Sphinx can be provided as examples (e.g. "@subject search text"). Any kind of content can be indexed as a field like this in Sphinx, and Cerb doesn't need to know about it for the queries to work.

  • [Setup/Search] Search functionality can now be configured from Setup->Configure->Search. Indexes are shown for any records that have full-text searchable content, including those contributed by plugins (e.g. message content, kb articles, comment content). A search engine can be configured for each index individually. By default, all content is indexed in the built-in MySQL Fulltext search engine, and no special configurable is necessary. However, dedicated search engines like Sphinx offer more features and higher performance.

  • [Search/Sphinx] Implemented support for the Sphinx search engine, an open source search server built for speed, scalability, and simple integration. This option requires Sphinx to be installed and configured separately, but you can expect searches to perform several times faster than MySQL Fulltext. Additionally, after switching to Sphinx you can drop the related fulltext_* tables in Cerb's database to reduce memory and storage usage, and to speed up processes like backups. Arbitrary fields can also be indexed by Sphinx and exposed to search (@status @subject @mask @headers, etc). This engine can be selected per-record from Setup->Configure->Search. Refer to the docs for setup instructions.

  • [Platform] Cerb now requires the 'mysqli' PHP extension, since the 'mysql' extension is deprecated in PHP 5.5+ and will be removed shortly.

  • [CHD-2954] [CHD-2549] [Performance/Scheduler/Maint] Improved the performance of the nightly maintenance scheduler job. Previously, this was inefficiently looking for broken links between records by performing expensive table joins.

  • [Devblocks/Code Cleanup] Fixed an issue where negative byte values weren't formatted by DevblocksPlatform::strToPrettyBytes(). It's common to have a negative number of bytes when computing deltas between two numbers.

  • [VAs/Placeholders/XML] Fixed the 'xml_decode()' function in placeholder scripts so it doesn't attempt to convert an XML document to an array. It now remains a SimpleXMLElement instance from PHP, which can be iterated, queried with XPath, etc.

  • [VAs/Placeholders/XML] Fixed an issue with the 'xml_decode()' function in placeholder scripts where namespaced XML documents didn't always work with XPath queries.

  • [VAs/Placeholders/XML] Added an 'xml_xpath()' function to placeholder scripts for querying the XML object returned by 'xml_decode()'. This can also return attributes.

  • [CHD-2955] [Performance/Cache/Plugins] The full cache of extension properties was being cleared every time any property changed, which created some extra database traffic. This happened often during scheduler /cron jobs. Properties are now cached per-extension, so the invalidation of a cache has no impact on extensions that didn't change.

  • [Cache/Performance/Platform] New cache engines can now be added through plugins. Caches improve the performance of Cerb by avoiding expensive database queries for content that hasn't been modified. Previously, only caching in the filesystem and memcache were supported. As before, objects are cached to the local filesystem by default without requiring any special configuration. Unlike before, the minimal set of 'bootstrap' caches required by the Devblocks platform are now always cached in the filesystem even when other cachers are available (e.g. plugins, extensions, global settings, tables, and classloader). This makes it possible to gracefully fail to disk-based caching if a previously configured plugin is no longer available, without introducing continuity issues. This also makes it possible to configure caching in a much more usable way from the browser in Setup, and to store cache configuration information in the platform. The cache-related settings in the framework.config.php file are no longer used and may be safely removed. If you were using memcache, you'll need to enable it again.

  • [Performance/Cache/Platform] The platform-managed settings of each plugin are now cached individually. This allows a plugin to invalidate its cache without requiring the settings of all other plugins to be reloaded from the database. The settings for the 'devblocks.core' plugin are always cached in the local filesystem, so they're available as the platform is starting up. This is where settings are stored for cache engine extensions (which can't load their settings from themselves, before they are set up).

  • [Cache/Performance/Platform] Server-side caching is now configured in Setup->Configure->Cache. Previously this had to be configured from the framework.config.php file, and only the filesystem and Memcached was supported. The cache engines provided by plugins show up here. When configuring a cache engine, its settings are tested before they are saved, and any configuration errors will be reported in the UI.

  • [Cache/Platform] When content is cached by Cerb in the local filesystem in storage/tmp/, they are now named "cache--" rather than "devblocks_cache---". This is mainly aesthetic, but some cache engines do have a slightly higher memory cost for longer key names. Many filesystems have file name length limits around 255 characters. Additionally, the shorter prefix means that files can be distinguished from each other after fewer characters.

  • [Cache/Security] When objects are cached to the filesystem, permissions no longer include 'world-readable' (in Unix parlance, they are chmod 0640). This helps prevent other users on the server from reading their content (Cerb still really shouldn't be installed in a shared hosting environment).

  • [Platform/Plugins] It's very common for JSON objects to be saved as plugin settings. The 'DevblocksPlatform::setPluginSetting()' and 'DevblocksPlatform::getPluginSetting()' methods now support an additional argument for automatically encoding and decoding JSON-based settings. This saves some redundant code when those settings are loaded or used in multiple places.

  • [Cache/Performance/Memcached] Memcached-based caching has been implemented as a plugin. It is configurable from Settings->Configure->Cache. The host, port, and key prefix can be set. A key prefix provides a way to namespace keys so that multiple applications can use the same Memcached datastore. A single host:port pair should be set, and a distributed setup should have multiple services placed behind a consistent hashing proxy like Twemproxy. This is a way more reliable way to provide highly available services, as opposed to handling them in the client (i.e. Cerb).

  • [Cache/Performance/Redis] Redis-based caching has been implemented as a plugin. It is configurable from Settings->Configure->Cache. The host, port, auth, database number, and key prefix can be set. Auth is optional, and useful for publicly hosted Redis databases (like Redis-to-go); although ideally Redis should be configured on an internal IP and be placed behind a firewall. The database number should be left blank when using a proxy in front of Redis, as many don't support multiple databases (and always use number zero). A key prefix provides a way to namespace keys so that multiple applications can use the same Redis datastore. A single host:port pair should be set, and a distributed setup should have multiple services placed behind a consistent hashing proxy like Twemproxy. This is a way more reliable way to provide highly available services, as opposed to handling them in the client (i.e. Cerb).

  • [Performance/Worklists] When a worklist has only one page of results with fewer rows than the paging limit (e.g. 6 rows out of 10), then an extra database query will no longer be executed to compute the total rows. The total records is simply the number of results on the first page. The extra query generally wasn't expensive in most cases, but it could potentially have run thousands of times per day on a moderately busy system.

  • [Performance/Platform] Several of the original database tables (e.g. created in 4.x and early 5.x) had a redundant unique index for the 'id' column. This isn't necessary since those tables already have a unique primary key. This added a slight delay when modifying records, and it wasted a little disk space. These redundant indexes are cleaned up by the update.

  • [Performance/Activity Log] The insertion of activity log entries has been optimized. Previously each insertion ran two database queries: one to insert a blank row and retrieve the new ID, and the second to update it. The same insert/update pattern is used elsewhere, but it's not necessary here because activity log records are never modified. This process now happens in a single query.

  • [Performance/Watchers/VAs] The code that retrieves a list of watchers for a record has been optimized. Previously, this was inefficiently finding results with a JOIN between links and worker records, which always bypassed the worker cache. It could also run a second query to retrieve worker data in some situations. The links are now retrieved as IDs without a JOIN, and the worker cache is always used to return record data.

  • [Performance/Mail/Parser] Lookups are now cached when checking if an email address is owned by a worker. This functionality is used frequently in the email parser where every bit of extra performance helps.

  • [Performance/Mail/Parser] Mail routing rules are now cached when processing new email. This functionality is used frequently in the email parser where every bit of extra performance helps. The cache is automatically cleared every 20 minutes in order to rebalance the order that rules are checked in based on how often they match.

  • [Performance/Mail/Parser] Multiple message headers are now inserted into the database in a single query. Previously, headers were inserted individually. Early profiling shows a 33% reduction in total queries when inserting many tickets at once (which the scheduler does quite often when polling POP3 mailboxes).

  • [Performance/Mail/Anti-Spam] Optimized the method used to compute spam probabilities on incoming mail. Previously, ticket and message data was always retrieved from the database, and scores were always saved directly back to ticket records. Now arbitrary content can be analyzed and the spam score and interesting words are returned without extra database queries being performed. In the parser, the anti-spam fields can be set at the same time as everything else, which eliminates several redundant queries for every message being processed.

  • [Mail/Parser/Anti-Spam] Previously, the anti-spam algorithm split subjects like 'CamelCapsWordsWithoutSpaces' into multiple words before analyzing them. Our research shows that these spam subjects haven't been popular for many years, so this code has been removed. Additionally, this approach had the side-effect of not analyzing words at all when they alternated cases every letter 'LiKe tHiS'. This content is now converted to lower-case and compared like normal. The subject of an email message generally only represents a small portion of its overall content, and this change shouldn't have a negative impact on spam classification.

  • [Performance/Mail/Routing] The parser's mail routing behavior no longer directly modifies records in the database. Instead, changes are made to the in-memory 'model' that the parser manages before a ticket is created. Any custom field values that are set from routing are now handled by the same code that sets custom fields on mail filtering behaviors (combining both actions into a single operation).

  • [Performance/Mail/Parser] Previously, the mail parser created a ticket record in several steps (ID, meta, message links, spam score, group and bucket). For instance, this prevented Virtual Attendants from detecting ticket changes too early in the process before the associated records were also inserted (custom fields, messages, activity log, etc). While this worked, it had the downside of being quite inefficient, because event listeners and Virtual Attendants still reacted to every record change, but just ignored those events when the fields they cared about weren't present. After a few design changes in the parser, tickets are now created in a single step, after all their related records have been created. This is far more efficient, and early profiling shows a decent performance gain.

  • [Cache/Platform] The cache service can now be instructed to store certain keys in local memory for the duration of the current request. This is useful when the same underlying data is used over a short time period by multiple features without any communication between them (e.g. worklists, Virtual Attendant behaviors). This can also be used when the cached data changes to frequently to persist for a longer period of time, or when the active cache engine can't manage volatile objects.

  • [Cache/Filesystem/Platform] The filesystem cache engine now supports exclusive locking when writing to files. Previously, in busy environments it was possible (albeit rare) for two webserver processes to simultaneously write to the same cache file, which could lead to inconsistent file contents.

  • [Cache/Redis/Platform] The Redis cache engine now generates a unique key prefix every time the cache is globally cleared. This effectively namespaces keys so that old keys will become inactive and be automatically cleaned up (assuming Redis is running in 'maxmemory' mode). This is proxy- and multi-tenant friendly since the 'flush' commands are never used. Objects are now given a default time-to-live of 24 hours to help facilitate this. This approach enables a lot of dynamic content to be cached without concern over exhausting the available memory (e.g. searches, records, worklists). The unique prefix is stored in Redis, and the automatic namespacing is cluster friendly. If the prefix is lost for any reason (expired, or Redis restarts) then a new one will be generated automatically and content will be re-cached by Cerb as it is retrieved again.

  • [Cache/Platform] Cache engines now declare whether they support volatile content with an isVolatile() method. This allows Cerb to adapt to the type of caching being used. For instance, thousands of cache files won't be created in the local filesystem since this can create I/O bottlenecks (particularly when keys are frequently written, since reads are likely efficiently cached in memory by the OS already). However, hundreds of thousands of cache keys could be written to Redis, Memcached, APC, or XCache without an I/O bottleneck.

  • [Performance/Search/Cache] The results of full-text searches are now cached. With a volatile cache engine (Redis, Memcached) they are cached for 5 minutes, and otherwise they expire at the end of the current request. This solves the long-standing issue where full-text searches were being performed twice when subtotals were enabled. In 6.7+, full-text search filter run first, so their results can be cached consistently regardless of other factors. This means that if more than one worker searches for the same thing, the intermediate results are shared, even if the rest of their worklist filters differ. Additionally, when a worker changes pages, and adds or removes filters, the expensive search no longer needs to run again. This is a major performance improvement, since most logged 'slow queries' are the result of full-text searches being repeated (by subtotals, and by workers changing other filters). For the best performance, you should enable a memory-based cache engine from Setup->Configure->Cache.

  • [Cache/Memcached/Platform] The Memcached cache engine now generates a unique key prefix every time the cache is globally cleared. This effectively namespaces keys so that old keys will become inactive and be automatically cleaned up. This is proxy- and multi-tenant friendly since the 'flush' command is never used. Objects are now given a default time-to-live of 24 hours to help facilitate this. This approach enables a lot of dynamic content to be cached without concern over exhausting the available memory (e.g. searches, records, worklists). The unique prefix is stored in Memcached, and the automatic namespacing is cluster friendly. If the prefix is lost for any reason (expired, or Memcached restarts) then a new one will be generated automatically and content will be re-cached by Cerb as it is retrieved again.

  • [Performance/Virtual Attendants] Previously, the target record of a Virtual Attendant event (like "New mail received by group") was always pre-loaded before the behaviors ran. Even though the behaviors efficiently shared the same record while running, this was still inefficient when no behaviors existed on the event point, because the data was still loaded anyway. The target record is now only "lazy loaded" from the database when it is first requested (which means at least one active Virtual Attendant behavior is watching the event). This change sped up the email parser by 200-300% during development profiling, and it should improve the performance of everywhere VAs are used in Cerb.

  • [Performance/Virtual Attendants] Virtual Attendant 'contexts' (the available fields and labels of a related set of records) are now cached in-memory for the duration of a request. This is particularly efficient in the parser, where the same VA behaviors might run hundreds of times in one /cron request. These contexts generally don't take long to build, but there is no reason to repeat that process hundreds of times when the cost of temporarily storing them in memory is negligible. This mainly saves CPU cycles.

  • [CHD-3321] [UI/Usability] All tabs that load dynamic content from the server now show a loading "spinner" image while waiting for a response. This gives workers a visual cue that something is happening in the background. Previously, tabs that were loading were either blank or they showed their outdated content until the new content arrived. This improvement is especially helpful on high latency connections.

  • [CHD-3640] [UI/Search/Usability] When performing a quick search, clicking on one of the examples in the tooltip will now automatically place it into the text field. This time-saving shortcut is particularly useful for fields like 'status' where a small number of discrete options no longer need to be typed.

  • [CHD-2067] [Security/Logins] Added a unique "salt" to worker password hashes to make them much more difficult to crack if they are ever exposed.

  • [Security/Logins] Password hash information is no longer included in the worker table, model objects, or caches. There is no reason to reference a password hash outside of the login process; and that can involve the database directly, where the results can be discarded afterwards. The more places that password hashes are stored, the more vulnerable they are.

  • [Security/Logins] Fixed an issue where password hash comparisons were taking place in MySQL rather than in PHP. This could unnecessarily leave password traces in MySQL log files and the process list.

  • [Performance/Cache] Retrieving a worker record by email address now uses the existing worker cache. Previously this was needlessly querying the database.

  • [Security/Logins] All logins, successful or not, are now slightly delayed on purpose. This adds an artificial cost to brute force attacks. If successful logins weren't delayed, smart attackers could just abandon a login attempt if it was taking noticeably longer than a successful login would. In the near future, this delay should be increased systematically for each consecutive login failure.

  • [Security/Mail/Relay] Improved the way that incoming email relay messages are authorized. Previously, the 'Message-ID:' header included the internal ticket ID, and the security hash used the worker's password to sign it. This meant when a worker changed their password the could no longer reply to any pre-existing relay messages.

  • [Mail/Relay] Incoming email relay replies are now associated with the message they were based on. This allows features like response times to be calculated properly. Previously, a relay reply was always associated with the latest message on a ticket.

  • [Mail/HTML/Inline] Fixed an issue where attachments weren't included when sending multiple inline images on the same line (like emoticons in a sentence), or on consecutive lines without blanks between them. (Technical note: the regular expression was too 'greedy' and combined all the inline image tags into a single result with unusable content.)

  • [CHD-2426] [CHD-1993] [Worklists/Export] The export feature on worklists now provides the ability to include all fields and linked records. Previously, only a small subset of the fields were available. For instance, exports can now include custom fields from the ticket's sender's organization. Additionally, large text fields like 'message content' are now available as well. This uses the same underlying functionality as the Web-API, but with the usability of the API. This also fixes the issue where only IDs were available for some fields, which weren't human-readable. A worker may now choose to export IDs, labels, or both.

  • [CHD-2426] [Worklists/Export] When exporting data from a worklist, human-readable labels are now provided for the fields. In CSV format, these are the headings in the first row. For XML and JSON, the labels are provided as a separate object next to the results. Previously, only arcane property names were returned, like 'cf_123'.

  • [CHD-2426] [Worklists/Export] When exporting data from a worklist, any number of fields can be selected now as a simple checklist. Previously the limit was 15. These fields can also be reordered by dragging them into place.

  • [CHD-3337] [Snippets/Worklist/Export] Snippet records and their content are now exportable from worklists in CSV, XML, or JSON formats.

  • [Worklists/Export] When exporting worklist results in JSON or XML format, field types are included along with the labels. These are useful for interpreting the data; for instance, discerning between a timestamp, checkbox, or number.

  • [Performance/VAs/Contexts] The message '_label' placeholder is now lazy loaded when first used. This requires an extra lookup to use the ticket mask in the output, which is inefficient if the placeholder isn't used. This was particularly inefficient in areas like the mobile plugin, API, and Virtual Attendants where there could be a hundred placeholder dictionaries open at the same time.

  • [Performance/VAs/Snippets] Optimized the way placeholder dictionaries lazy-load content. Previously, cycles were being wasted crawling through linked contexts in the dictionary every time a placeholder was loaded. For instance, if requesting 'ticket_latest_message_sender_full_name' and 'ticket_latest_message_sender_address', data was being recomputed that could have been cached when the dictionary was created. This only cost a few milliseconds, but in some areas that code can run many times (worklist export, API, VA, mobile).

  • [Performance/Platform/Contexts] Optimized the way multiple placeholder dictionaries retrieve their values. The feature was originally designed to be used by Virtual Attendants for a single target, but it now powers the mobile UI, web API, Virtual Attendant list variables, and worklist exports. Previously, each dictionary loaded its values independently, which created a lot of redundant database queries (e.g. multiple tickets loading the same organization or sender information). Now the dictionaries are first analyzed to see what linked records they have in common, and only distinct records are loaded. Duplicates records are served from a high-speed temporary cache.

  • [Worklist/Export/JSON/Performance] Worklist exports in JSON format are now streamed so that peak memory usage remains low. Previously, all the records loaded into memory before they were displayed.

  • [Worklist/Export/XML/Performance] Worklist exports in XML format are now streamed so that peak memory usage remains low. Previously, all the records loaded into memory before they were displayed.

  • [Worklists/Export/Usability] When exporting a worklist to CSV, JSON, or XML, a picker menu is now displayed to quickly search for and select any number of desired fields. Previously, fields had to be selected from a fixed list of 15 dropdowns. The order of the exported fields can be rearranged by dragging them into place.

  • [Worklists/Export/Usability] When exporting a worklist, an option is now provided to automatically convert timestamps into a human readable format (e.g. "Sun, 06 Apr 2014 02:58:03 -0700"). Previously, timestamps were always in Unix epoch format (e.g. 1396778283), which complicated working with the exported data in programs like Excel.

  • [Worklist/Export] Worklist exports now generate output incrementally while displaying the current progress in the browser. This helps to avoid the time and memory constraints inherent in long-running processes. When an export is complete, a download link is shown. Previously, exports attempted to run in a single request, which would become unsuccessful after a list reached a certain size.

  • [Worklists/Export/Messages] Added 'export' functionality to message-based worklists.

  • [Worklists/Export/Notifications] Added 'export' functionality to notification-based worklists.

  • [Security/Cache/Filesystem] The filesystem cache now appends a unique suffix to the generated file names in the storage/tmp/ directory. This helps protect cache file contents in misconfigured environments where the storage/ directory contents are readable by web browsers, since the files no longer have predictable names like 'cache--ch_workers_all'. This is simply a last line of defense against an attacker scanning for sensitive info in the cache, and it doesn't provide any protection if the web server is very misconfigured to provide a directory index of all the cache files. Make sure you web server is blocking access to all these directories (api/, features/, libs/, storage/).

  • [API/Worklist/Export/Placeholders] Record IDs are now available as placeholders through the API and when exporting worklists.

  • [CHD-3421] [Sessions/Usability] The expiration on worker sessions is now automatically extended during activity. Previously, a cookie was set when the worker logged in, and if sessions had an expiration of '1 week', then the cookie would obnoxiously expire at that future time even if the worker happened to be logged in and actively using Cerb. Now the session expiration options are all based on the time elapsed since the last worker activity. If sessions are set to expire after a week of inactivity, then any activity by that worker will extend the expiration by another week.

  • [Security/Sessions/Setup] Added two new shorter duration session expiration options to Setup->Configure->Security: "after 6 hours of inactivity", and "after 12 hours of inactivity". These are useful now that session expirations only count a continuous period of inactivity.

  • [CHD-3324] [Setup/Workers/Usability] Administrators can now change worker passwords from Setup->Workers. In some situations, worker email addresses are also managed by Cerb, so having account recovery information sent there doesn't work. If the password field is left blank on a new worker, then a temporary password will be generated and emailed to them. Some login authenticators (e.g. OpenID, LDAP) will ignore the local password during the login process.

  • [Setup/Workers] When a worker account is deleted, their sessions will now be properly deleted as well.

  • [CHD-3386] [Calendars/Search/Usability] Quick search can be used to filter by calendar on calendar event and recurring event worklists.

  • [Calendars] Fixed an issue on calendars where a long-running event wouldn't display properly on multiple days if it started and ended in a different daylight savings time mode. For instance, an event that started the day before DST and ran for two weeks would only display on a single day in the calendar. This affected both manual events and events synced from worklists (e.g. tickets).

  • [Performance/Virtual Attendants/Mail] Optimized the way changes are detected on ticket records. Previously, every time a record was updated it was first retrieved from the database, and then its original and new values were computed for each field. This was inefficient because there are only a few important fields that trigger functionality (move, assign, change status). Internal fields used by Cerb also no longer trigger the expensive 'changed field' checks (e.g. elapsed time, merging, splits). When important field changes do happen, existing objects are efficiently reused rather than performing redundant lookups.

  • [Security/Platform/Plugins] The DevblocksPlatform::importGPC() and ::importVar() helpers can now specify types like array:integer, array:bit, and array:boolean. This will enforce arrays and typecast their contents. This is particularly useful to prevent SQL injection vectors when accepting IDs from an HTML form and sending them to the database. Previously, these variables needed to be sanitized in a second step.

  • [Virtual Attendants] Events can now display and store customizable parameters per Virtual Attendant behavior. This allows for powerful abstraction. For instance, a single abstract event like 'Record changed' can have a 'Record type' parameter, which allows each behavior to adapt to the conditions and actions of a specific record type. Previously, abstract events could only work with the fields and actions that every type of record had in common (i.e. not very much), and otherwise would require dozens of redundant events like 'Ticket changed', 'Task changed', etc.

  • [Virtual Attendants] Events can be configured to only trigger when specific parameters match on the listening behaviors. This is useful for new abstract behaviors like 'Record changed' where they may be 30 listeners (one for each type of record), but only one record type is implicated in the current event. Sending the event to only that listener is far more efficient. Previously, an event could restrict itself to one particular behavior (in the case of custom behavior macros), but there was no way to target a collection of behaviors as a related group.

  • [CHD-3679] [Virtual Attendants/Record Changed] Added a new 'Record changed' event for Virtual Attendant behaviors. This is the first of a series of new abstract events. Instead of having 30+ distinct events for each type of record that can change, all behaviors are created on this single event. The event triggers whenever any record is changed, and each listening behavior specifies which record type it wants to be notified about. When the 'Record changed' behavior specifies its type, all of the conditions and actions from a 'custom behavior' of that type then become available as well. The placeholders of the event provide '(New)' and '(Old)' values for every field, so a behavior can react not just to the fact that a field changed, but also to the fact it changed from a specific earlier value. For instance, a Virtual Attendant behavior could trigger only when tickets move from one specific bucket to another within the same group, or when a 'Priority' custom field changes from 'High' to 'Low'. The possibilities are endless. It's recommended to use the 'Custom script' condition when comparing old and new values.

  • [Mail/HTML/Inline] Fixed an issue where attachments weren't included when sending multiple inline images on the same line (like emoticons in a sentence), or on consecutive lines without blanks between them. (Technical note: the regular expression was too 'greedy' and combined all the inline image tags into a single result with unusable content.)

  • [Calendars] Fixed an issue on calendars where a long-running event wouldn't display properly on multiple days if it started and ended in a different daylight savings time mode. For instance, an event that started the day before DST and ran for two weeks would only display on a single day in the calendar. This affected both manual events and events synced from worklists (e.g. tickets).

  • [Mail/Compose/Usability] When composing mail, the text on the submit button now reads "Send message" instead of "Save changes". The latter confused some workers into believing a draft would be saved rather than sending the message.

  • [CHD-3723] [Virtual Attendants/Mail/Headers] Fixed an issue where 'message headers' conditions weren't configurable on "New mail on a watched conversation" behaviors.

  • [Virtual Attendants] Fixed an issue on custom Virtual Attendant behaviors where the target VA was always the one running, even if another target was given. For instance, if one VA was monitoring another on a 'Record changed' event, and commenting on the target when it was disabled, the comment was always on the observer and not the target.

  • [Virtual Attendants/Performance] Improved the performance of Virtual Attendants by not generating their internal data twice. The existing event wasn't being passed to the running behavior when responding to an event, or in the simulator. This meant that every behavior was generating their own copy of the event. In the simulator, this caused placeholder data to load twice.

  • [Support Center/Aesthetics] Made minor cosmetic improvements to the default Support Center stylesheet: removed unnecessary borders and lines; improved button styles; added more padding to content, lists, and sidebars; added more padding to headings; removed underlines from navigation tabs; added more hover effects; stylized worklists.

  • [Support Center/Knowledgebase/Search] Simplified the knowledgebase search options in the Support Center. Previously this displayed "all words", "any words", and "phrase". Cerb will now attempt to determine this automatically like it does on the worker side.

  • [CHD-3687] [Support Center/History] The Support Center can now be configured to display any combination of fields and custom fields as columns on the Ticket History worklist. For example, this makes it possible to share the value of fields (e.g. owner, priority, first response time) with clients. Previously, the columns on this worklist were limited to the bare minimum (subject, last wrote, updated).

  • [Support Center/History] In the Support Center, when the 'Subject' field is explicitly configured as a column then the worklist will display with records on a single row. Otherwise, the subject is displayed on its own line to make more room available for other columns.

  • [Support Center/Knowledgebase] The Support Center can now be configured to display any combination of fields and custom fields as columns on Knowledgebase worklists.

  • [Support Center/Knowledgebaae] In the Support Center, when the 'Title' field is explicitly configured as a knowledgebase column then the worklist will display with records on a single row. Otherwise, the title is displayed on its own line to make more room available for other columns.

  • [Support Center/Branding/Usability] A simple 'Logo URL' setting can now be configured for Support Center portals. Previously, logos could be changed by editing the header.tpl custom template, which was more flexible but also more complicated. That template may still be modified for more complex customizations like mimicking the look and feel of an existing site.

  • [Support Center/Branding/Performance] A 'Favicon URL' setting can now be configured for Support Center profiles to display an icon next to the URL (and in bookmarks). Previously, this had to be configured by modifying the index.tpl custom template, which could cause unnecessary conflicts during an upgrade. This also improves performance because browsers perform an extra HTTP request looking for a favicon when one isn't specified, and the Support Center was going through the work of rendering the home page again in response to these requests.

  • [Support Center/Performance] The Support Center now caches visitor session lookups globally for the duration of the request. Previously, features could load the session from the database multiple times.

  • [Virtual Attendants/Actions/HTTP Request] When using the 'Execute an HTTP request' action in Virtual Attendants, custom headers can now be provided (including placeholders). This makes it possible to integrate with many more web services.


Properties ID: 000105   Views: 5077   Updated: 8 months ago
Filed under:
knowledgebase comments powered by Disqus