Release notes for Cerb 7.0
Cerb (7.0) is a next-generation, major functionality update released on May 26, 2015. It contains over 110 new features and usability tweaks from community feedback.
See: http://wiki.cerbweb.com/7.0
[Platform/Storage/Plugins] Virtualized the way filesystem paths work for storage and plugins. In most cases the previous way worked fine (where cerb/storage/ was the assumed path), but this change makes it possible to host multiple instances of Cerb in cloud environments where the individual storage paths aren't located at cerb/storage/. With a single site, that path could be symlinked to anywhere else, but when multiple sites share the same Cerb files the solution needs to be at the application-level rather than in the underlying filesystem. This change makes it much easier to run and scale cloud deployments of Cerb using distributed filesystems, etc. The storage location can even change while Cerb is running and installed plugins won't be affected (where, previously, their full paths including storage/ were stored in the database; now we just use 'plugins/plugin.id').
[CHD-1870] [Platform/Performance/Scaling/Database] Cerb now fully supports master/slave database replication setups, where writes are sent to the master(s) and reads can be distributed among many slaves. Master/slave replication has always been possible for high-availability and failover, but Cerb never took advantage of the idle slave databases for improving read performance. Previously, master/slave query splitting was only naively possible by using database proxies like MySQLproxy or MaxScale as an intermediary. Those tools simply sat between Cerb and the database and routed SELECT queries to the slaves and everything else to the master. That process couldn't handle some important types of queries that depend on deeper application knowledge (temporary tables, character encoding, etc). By handling the routing to master or slave connections directly in Cerb, we can make those decisions very intelligently while also optimizing performance.
Meta information about the database (e.g. table list, table schemas) is always read from the master to ensure that the most recent information is used. Similarly, all database queries executed by the installer and update process are sent to the master because "eventual consistency" (updates in slaves slightly lagging behind updates in the master) could cause inconsistencies. These processes run infrequently and don't have a major impact on performance or scaling. Temporary tables are created on the same connection where they're used (e.g. master for maintenance queries that modify the database, slaves for searches that join temporary tables created from external search services). All the rest of the read-intensive content -- like workspaces, worklists, dashboards, reports, and profile pages -- are almost exclusively sent to slaves. Utilizing database slaves to serve most of the content is where the major performance improvements and scalability come from.
The use of database slaves for improving read performance can be enabled by setting the APP_DBSLAVE* values in the framework.config.php file (host, user, password). While a single slave host can be defined in Cerb, you can put a proxy or load balancer in front of multiple slaves to scale. This could rotate between the slaves for each new connection (e.g. round-robin, least loaded, most current). Similarly, master-master replication can be utilized by specifying a proxy or load balancer for the master host. Since Cerb often generates multiple parallel HTTP requests for a single page (the outer page, a tab's content, and several worklists or widgets), multiple database slaves can be utilized to render this output more quickly.
Cerb will always route queries to either a master or slave, but when slaves aren't configured then the master serves as both roles. In this case, a single connection will be used (instead of two) to minimize wasted resources on the database server.
[Platform/Database/Plugins/Developers] To use the new read/write splitting to master/slave databases, developers should update their plugins to use the new database functions. For instance, $db->Execute() has been deprecated in favor of ->ExecuteMaster() and ->ExecuteSlave(). Existing calls to ->Execute() will always be sent to the master. Likewise, new master/slave methods exist for ->GetOne(), ->GetRow(), and ->GetArray(). Existing calls to the generic, deprecated method will always be sent to read slaves. To optimize performance, these queries should be made explicitly as reads or writes so they can be routed accordingly.
[Platform/Localization] The language encoding in the framework.config.php now defaults to UTF-8. Previously, this defaulted to ISO-8859-1 (Western Latin) if the database wasn't originally created with UTF-8 default encoding (as MySQL's default was latin1). Using UTF-8 has been our recommendation for many years. UTF-8 can be used to display the web pages even if the database continues to use latin1.
[Platform] Removed the deprecated cache settings in the framework.config.php file since caching is now configured from Setup->Configure->Cache in the UI.
[Platform] Removed the deprecated APP_DB_DRIVER setting in the framework.config.php file since 'mysqli' is now required.
[Code Cleanup] Added APP_DBSLAVE* settings to the framework.config.php file.[Platform] Defaulted DB_CHARSET_CODE to 'utf8' in the framework.config.php file. If you're still using legacy 'latin1' encoding, now is a good time to convert your database to UTF-8 to properly handle multibyte languages. You can also just fix the inevitable conflicted line in this file after upgrading if you want to continue using your original settings. This new default was selected because it will match how most people are configured and cause a conflict for the least amount of people (i.e. not changing superior 'utf8' back to inferior 'latin1' on existing installs during the upgrade).
[Performance/Workspaces] If the schema of a worklist is unchanged during a request (page, sort by, columns, filters, etc), then it will no longer be redundantly persisted to the database. Previously, most worklists were always saved after being accessed regardless of whether or not they had changed during the request. This created some extraneous write traffic on the database (and any subsequent replication, binlog backups, etc). This is now handled more efficiently for all worklists, including those provided by plugins.
[Performance/Sessions] The worker activity information in "Who's Online" now only updates once per request. Previously, it was possible for multiple activities to be sequentially written to the database even though the last one would replace all the earlier ones. This created some extraneous write traffic on the database.
[Performance/Sessions/Profiles] Previously, all worker activity for "Who's Online" was updated once per 30 seconds. This waiting period has now been extended to once per 60 seconds. When this interval was first established, there wasn't a way for some activities (e.g. viewing a ticket profile) to ignore the waiting period and always update a worker's activity. Now that this is possible, the default activity can wait longer to update in order to reduce database write traffic.
[Performance/Database] Improved the performance of several operations involving temporary tables (e.g. searching) by ensuring that primary keys were added to the temporary tables.
[Performance/Database] Removed extraneous checks for the database connection status during a single request. Database connections no longer open until they're first used, and this connection checking is now handled in a simpler way.
[Performance/Database] Prevented extraneous database query lookups when the ID of a record is zero (non-existent). These extra lookups were happening in places like ticket profiles, where organizations are looked up for senders, and the orgs may be blank.
[Performance/Worklists/Database/Developers] Worklists now automatically persist worker changes (page, sort, columns, filters) and only update the database when necessary, once at the very end of the request. Previously, developers had to explicitly write a ::setView() call to persist changes. Persistence was also forced in some places in the API as well. This led to a situation where changes to a worklist could be persisted multiple times per request, even when there weren't any changes. This created extraneous write queries to the database server.
[Performance/Database/Cache] When Cerb caches all records for small sets (workers, roles, groups, buckets, custom fields) it will always use the master database. These caches are usually invalidated based on changes taking place in the database, and retrieving the latest record from the master ensures the most recent copy. Reading immediately from a slave could cache records prior to the change taking place if replication was slightly delayed.
[Storage/Performance/Database] The database storage engine will now use the default master/slave connections when no external host is specified. The connections are also established lazily, so a slave read doesn't require that the master be contacted at all.
[Platform/Tests] Added a unit testing framework and many new tests to the 'tests/' directory of the project. This can be used for automatically testing builds during clones, commits, pull requests, etc. Unit tests help to ensure that developers and contributors don't break existing code while implementing new features or fixing bugs. We have many testing scripts that will be consolidated here so they're accessible by the entire community. The tests are run from the command line and access to the directory should be blocked for all web traffic.
[CHD-374] [CHD-4003] [Mail/Transports] Multiple outgoing mail transports may now be configured from Setup->Mail->Transports (e.g. SMTP, Mailgun). Previously, it was only possible to have a single outgoing mail server configured for the entire Cerb installation. This change makes it easier to manage multiple brands in a single Cerb instance, where various sending domains need to use different SMTP servers or authentication methods. It's also possible to implement new transports through the plugin system to take advantage of special features like the Mailgun API (open/click tracking, campaigns, auto-unsubscribe links, etc). Each reply-to address (the addresses Cerb sends mail as) can now specify a particular mail transport to use. A default mail transport can be configured. The previously configured SMTP server will be automatically created as the new default during the upgrade process.
[Mail/Transports] Added a new 'Null' mail transport. This discards outgoing mail without delivering it, which is useful for development, testing, and evaluation environments where live mail should not be delivered. Previously, the same functionality was possible by configuring a null transport in a mail server like Postfix -- or using a dummy mail server like the one provided by Python -- but those options require several extra steps. Now Cerb can simply be configured to not deliver mail, and it can be installed on test machines without needing access to a live mail server during installation.
[Installer] Updated the aesthetics of the installer to reflect the newest Cerb style.
[Installer/Mail] The installer can now configure outgoing mail using the SMTP or Null transports. The latter makes it easier to set up development, testing, or evaluation environments.
[Installer/Workers] When the installer creates the initial administrator account, the worker's first and last name can be provided so they don't need to change that after logging in.
[Installer/Workers] When the installer creates the initial administrator account, the worker's timezone can be set. The initial value is automatically detected.
[Installer/Workers] When the installer creates the initial administrator account, the worker's default calendar is now automatically created. Previously, this had to be created manually after logging in, while adding subsequent new worker accounts would automatically create those calendars.
[UI/Performance] When remembering the previously selected tab on a page, Cerb now efficiently stores this information in HTML5 localStorage in the worker's browser (client-side), rather than persisting it to the session (server-side). To the worker this behaves identically; but from a performance standpoint, this optimizes away a lot of needless session updates that wrote to the database (and possibly needed to replicate, and/or be backed up in the binary logs, etc).
[Setup/Mail/Usability] In Setup, changed the 'Mail->POP3 Accounts' menu option to 'Mail->Mailbox Accounts'. There can be multiple types of mailboxes (POP3, IMAP, and possibly even API-driven accounts), so naming the menu option as only one of these was a source of confusion.
[UI/Aesthetics/Gravatar] When the Gravatar plugin is enabled, profile pictures for workers and contacts are now rendered as circles rather than squares. This provides a more modern aesthetic.
[Mail/Reply/Usability] Changed the default behavior of the mail reply textarea to not auto-grow as the user types new lines. This can be re-enabled from worker settings. There were numerous reports of it causing lag in some browsers, as well as causing some weirdness with scrollbar positions.
[Platform/Dependencies] Updated the jquery.atwho and jquery.caret plugins to their latest versions.
[Snippets/Usability] Fixed some usability issues with the snippets popup when composing and replying to mail. In some browsers (especially Internet Explorer) the focus of the reply textarea could be lost when inserting snippets. Additionally, when closing the snippets popup the reply textarea scrollbars could skip around and require manual repositioning.
[Mail/HTML] When reading mail, HTML messages are now displayed inline without having to click the original_message.html attachment to view them.
[Platform/CSS/Developers] The cerb.css stylesheet is now built using the Sass CSS preprocessor. The source files are in the /install/extras/developers/css/cerb.css/ directory. This makes it much easier to manage the styles consistent for a large and complex application like Cerb.
[Platform/Performance] Email address and organization records are now retrieved more efficiently with a local memory cache for the duration of the request.
[CHD-3656] [Plugins/Gravatar] The Gravatar default icon is now served directly from Cerb. Previously, this was served from a static URL, which was triggering browser warnings for SSL connections. When the Cerb install is behind a firewall or on an intranet, the Gravatar plugin can now be configured to use any URL for the default icon.
[Platform/Dependencies] Updated the jQuery hoverIntent plugin from version r7 (2013-03-11) to 1.8.1 (2014-08-11).
[Mail] On the ticket conversation history, the 'Date:' for a message was only being displayed if the raw message source contained that header. However, Cerb uses its own timestamps, which contain a default if a date wasn't provided. Consequently, this field is now always shown for every message.
[Platform/Search] Fixed an issue when attempting to run cron.maint to purge deleted records before the full-text search indexes have been built.
[CHD-3995] [Comments/@Mentions] When using @mentions to notify workers, the auto-suggestions now display each workers nickname, and filtering by that nickname (in addition to the full name) is now supported.
[CHD-4040] [Mail/HTML] When sending an HTML message using ordered lists, the generated plaintext part will now use numbered bullet points rather than unordered points.
[Platform/Tests] Added automated tests that create a new database, run all the patches, and add a default admin worker. This is used as the baseline for fully automated browser testing with Selenium.
[Platform/Tests/Selenium] Added automated browser tests using Selenium to log in to a fresh installation, close the tour, add the default mail page, configure mail transports, reply-to, add a default role, add a group, create co-workers, import orgs and contacts with a CSV file, add an owner custom field to tasks, enable plugins, configure calendars, etc.
[Skills] Implemented skills for matching workers with the most appropriate tickets, tasks, calls, opportunities, etc. Skills on a worker are considered to be competencies, and skills on other records are considered to be requirements. This informs the 'qualification' metric in the new recommender service. Skills have the following levels: none, basic, intermediate, advanced, and expert. A worker with a higher level of skill than the requirement is considered to be 'overqualified', while a worker with a lower level of skill than the requirement is 'underqualified'. A worker with the exact same skill level as a requirement is the best fit. This also provides a much more sophisticated way to automatically assign records to workers.
[Skills/Skillsets] Added skillsets as a way to group related skills. For instance, a Development skillset may contain skills like 'PHP', 'jQuery', and 'MySQL', while a 'Sales' skillset would contain 'Prospecting', 'Qualification', and 'Negotiation'. It's much quicker to add a single skillset to a record than trying to find and add all the individual skills. Skills in a skillset are ranked by dragging a slider to the desired level of proficiency.
[Mail/Importance] Added an 'Importance' property to ticket records as a scale between 0 and 100. Importance is set by dragging a slider when editing tickets, rather than dealing with arbitrary labels like 'low', 'normal', and 'critical'. The importance property is used as a metric in the new recommender system. Previously, prioritization was handled using custom fields, but that approach was inconsistent between Cerb environments. Additionally, using discrete priority categories made it more complicated to create escalation workflows; where the importance field can simply be incremented or decremented by some amount in the range of 0 to 100. This means that Virtual Attendants can simply add a fixed value to the importance of new tickets for organizations with a service-level agreement (SLA).
[Mail/Buckets] Removed the 'is assignable' property from bucket records. This feature is now handled more robustly by group responsibilities. Previously, the entire bucket was marked as containing assignable work or not. Now, each group member can be explicitly assigned responsibilities for the various buckets. Buckets with no assignees are assumed to contain non-assignable work (for the purposes of the assignment recommender, etc).
[CHD-4077] [Virtual Attendants/Mail/Relays] Fixed an issue where the 'Relay email' action didn't list all available workers when used in an app-owned behavior.
[Workspaces/Worklists] Fixed an issue with required filters on worklists that use placeholders (like 'current_worker_id'). In some situations, these were being converted to the actual current worker, which prevented them from displaying properly for other workers.
[Mail/Groups/Buckets] Group inbox buckets are now actual records in the database. Previously, inboxes were virtual records with id=0. This simplified some early workflows since 4.0, but it also made several queries less efficient because the group had to be compared every time as well. For instance, filtering by a 'Sales' inbox would require filters like (group_id=3 and bucket_id=0) rather than just (bucket_id=5). The 7.0 update automatically creates an inbox bucket for each group and moves the appropriate tickets into it, and the configuration of Virtual Attendant behaviors, mail routing rules, and worklists will be automatically updated.
[CHD-2839] [Mail/Worklists/Search] The group and bucket filters on ticket worklists are now independent. Previously, the group filter managed both of them. When clicking group and bucket subtotals from a worklist sidebar, only a single filter is added now. The bucket filter prefixes group names, like 'Sales: Inbox'. Filtering by inboxes now works as expected; where previously, adding a "not in" filter based on group inboxes excluded every group's inbox.
[CHD-3580] [Mail/Worklists/Usability] The 'move' action on ticket worklists is now more efficient. Previously, this displayed a searchable menu with a long list of every group and bucket. Now it simply displays two linked dropdowns, with the first selecting a group, and the second selecting one of its buckets. This is more consistent with how groups and buckets are set in the rest of the app.
[Machine Learning/Platform/Devblocks] Added a neural network service to Devblocks to support trainable, real-time machine learning in various features and for third-party plugins.
[Worklists/Groups/Explore] Implemented 'explore' mode for group worklists.
[Worklists/Workers/Explore] Implemented 'explore' mode for worker worklists.
[Mail/Buckets/Usability] Group buckets are now always listed in alphabetical order. Previously, buckets were manually ordered. This made it less intuitive to find a specific bucket in a list. Ticket worklist subtotals by bucket now sort properly by count.
[Worklists/Ticket/Usability] The 'Group' column on ticket worklists now provides links to each group's profile.
[Worklists/Ticket/Usability] The 'Bucket' column on ticket worklists now provides links to each bucket's profile.
[Worklists/Ticket/Usability] The 'Owner' column on ticket worklists now provides links to each worker's profile.
[Groups/Peek/Usability] Added a 'view full record' permalink to group peek popups.
[Mail/Buckets/Usability] Added worklists and profile pages for bucket records.
[Groups/Usability] Groups can now be marked as 'public' or 'private'. The content (e.g. tickets/tasks) in a public group are visible to non-members. This is very useful if you want only a few workers to be responsible for a group like Support, Billing, or Development, but you want all workers to have access to them. Private groups hide their content from non-members. Previously, all groups were treated as if they were private; which confused member responsibilities.
[Groups/Setup/Usability] Previously, the management of groups was handled in three different places (Setup->Groups, the groups page, and group profiles). These areas have been merged for simplicity. New groups can be added from Setup, but they are now configured directly from the profile page. The 'groups' page (in the top right of the navigation menu) has been removed.
[Mail/Importance/Usability] The new 'importance' field on ticket records now defaults to 50/100 rather than 0/100. This allows importance to be adjusted up or down upon initial record review. When sorting by importance, this also allows new tickets to be reviewed before anything that has been set to a lower priority (where, previously, everything on the low priority end was mixed together with new tickets).
[Notifications] Notifications are now more closely related to Activity Log entries. A notification message can link to multiple records (e.g. actor and target). This is also more readable since the entire notification isn't an underlined link. Previously, notifications were just a message and an arbitrary link, where the link could become stale if the record moved (e.g. Cerb install changed URLs/paths). Notifications are now based on the same events as the Activity Log. The upgrade process will automatically convert any existing notifications to the new format.
[Notifications/Subtotals] Notification worklists can now be subtotaled by activity type. This makes it much easier to clear out many notifications of the same type (e.g. "Worker followed a record").
[UI/Aesthetics/Icons] The icon style of the user interface (UI) has been modernized. Previously, we used two different sets of sprite icons. These images had conflicting styles and distracting colors which led many people to comment that the UI looked "dated". The new icons are font-based (via Glyphicons), which allows them to display cleanly at any size, and to be colorized consistently using standard CSS. They are monochromatic in color and "flat" in style.
[UI/Aesthetics/Buttons] The style of buttons throughout the UI has been improved. Button icons are now black on gray, and the labels are bold. This makes buttons more pronounced and recognizable compared to normal content.
[UI/Aesthetics/Worklists] The style of worklists has been improved. The list icons in the top right of the blue bar are now white (rather than multicolored). The action buttons below the list are black on gray. The peek button (shown when hovering over a row) now uses a standard "new window" icon.
[Groups/Responsibilities] Group managers can now configure per-bucket responsibilities for group members. Responsibilities are displayed as a "delta" slider. By default, members have average responsibility for every bucket (the midpoint of the slider). By increasing or decreasing these responsibilities, actionable records (e.g. tickets, tasks) can be assigned and escalated to the proper members much more easily. When a member has zero responsibility for a bucket, they are not shown that work when filtering by responsibility. This makes it simple to partition work within a group and hide records that are not relevant to particular workers. Previously, all group members were considered to be fully and equally responsible for every bucket within the group.
[Worklists/Watchers/Usability] The watcher buttons on worklists are now more condensed and subtle. Previously, these buttons were green by default and they displayed a (+) icon with a watcher count. Now, the only label on the button is the watcher count (which is 0 by default). The button is gray when the current worker isn't watching the given record, and green when they are.
[Worklists/Watchers] Workers can no longer add or remove each other as watchers from worklists or profiles. This concept is superseded by the new "recommendations" feature. Watching a record should only happen with a worker's permission.
[Mail/Messages/Custom Fields] Custom fields and fieldsets may now be set directly on message records. These fields are displayed at the bottom of each message in a ticket conversation (in the same format as other record properties). This is very useful for storing per-message data like customer satisfaction ratings, sentiment tracking (satisfied/unsatisfied), etc.
[Setup/Mailboxes] Mailbox accounts are now first-class records with worklists, profiles, peek, etc. Internally, all references to 'pop3 account' have been changed to 'mailbox'.
[Setup/Mailboxes/Log/Notifications] If a mailbox fails while downloading mail, a notification is sent to all admins with a direct link to the mailbox record. The event is also recorded in the record's Activity Log. Errors are recorded after 2, 5, 10, and 20 consecutive failures. Previously, notifications were sent to admins with a link to the setup page (rather than the individual account) and the event wasn't permanently logged.
[Plugins/Time Tracking] Fixed an issue that prevented the time tracking plugin from migrating directly from version <= 5.1 to the latest.
[Activity Log] Arbitrary activity log entries can be created using the 'custom.other' event point. This can be done from plugins or the REST API. In most cases, it's still ideal to explicitly define new events from a plugin. This allows them to be subtotaled, filtered, etc.
[Recommendations] A recommendation system has been implemented to assist human and Virtual Attendant dispatchers in assigning and escalating work. For instance, when viewing a ticket "peek" popup, currently recommended workers are displayed along with the ability to make new recommendations. Next to each worker is a summary of their current status (online/offline), their next 24 hours of availability, their current workload (assignments, recommendations, and unread notifications), and their responsibility for the currently selected bucket. When the group/bucket dropdown changes, the ranking of suggested recommendations are updated in real-time.
In environments with many interchangeable workers on different schedules, recommendations are strongly encouraged compared to changing the owner of a record. In previous versions, when a record was assigned to a worker, it could disappear for everyone else. This could give the illusion of an issue being handled even if that assigned worker was unavailable. With the new system, several workers can be recommended at once, and the first to accept the work can assign themselves as the owner. The notifications for the other recommendations can be cleared (even if unread) so those workers aren't bothered to look at a record that is already being handled.
With recommendations, a worker can unassign themselves after responding so that the record is available for anyone else to handle (e.g. end of shift, vacation, etc). When workers leave themselves as a recommendation while unassigning, they will be given first priority based on their past involvement if those records need attention again in the future. Without recommendations, a different worker may be assigned for each subsequent reply, even if the original responder was currently available, which is very inefficient (as each new worker has to redundantly get up to speed with the issue before contributing).
When there are multiple recommendations on a record, the recommender system considers the bucket responsibilities, availability, and workload of each recommended worker. This makes it easy to craft Virtual Attendant behaviors that use these metrics when selecting the best assignee.
Currently, bucket responsibility is the primary metric used for recommendations. In near future 7.x updates, recommendations will likely be expanded to utilize many more metrics (e.g. importance, availability, skill qualification, approachability, past involvement, lateness, etc). Most of the work is already done to collect and use these metrics, but we want to gather usage feedback based on the simpler responsibility-based implementation before making things more complicated. During development, we also had experimented with the recommender system as a learning neural network (i.e. supervised machine learning), and that's likely to be something we'll revisit in a future update.
[Recommendations/Tickets] Ticket worklists can now be filtered to records that have been recommended to a specific worker, or that have not been recommended to any worker. This greatly simplifies dispatching workflows.
[Skills/Profiles/Workers] A 'Skills' tab is now displayed on worker profiles. The worker whose profile it is, or any admin, will see an 'Edit' button at the top of the tab to modify the skills and experience levels.
[Profiles/Workers] Worker profiles now have a tab to display their primary calendar. Previously, profiles only displayed availability, and a link displayed the primary calendar on a separate page.
[Profiles/Groups/Keyboard] Added keyboard shortcuts to group profiles.
[Profiles/Workers/Keyboard] Added keyboard shortcuts to worker profiles.
[Worklists/Sort] Implemented the ability for a single worklist column to sort by a composite of any number of underlying fields. For instance, on tickets, sorting by the 'responsibility' column can sort by responsibility and then by importance.
[Ticket/Worklists] When sorting by the 'Importance' column on ticket worklists, the list will also sub-sort by oldest tickets (i.e. most important and oldest first).
[Tickets/Worklists/Responsibilities] Ticket worklists can now include a 'Responsibilities' column. This automatically filters the worklist to only records in buckets that the current worker is responsible for. When sorting in descending order, records are shown: highest responsibility + highest importance + oldest. This is the simplest way to provide personalized worklists to every team member. The record order by can modified by changing the worker's bucket responsibilities, or the importance of individual tickets. Previously, tickets were usually only sorted in recently updated order, which inefficiently showed every worker the same exact list. SLAs can easily be supported by having a VA increment the importance of their new tickets.
[Worklists/RSS/Security] Removed the RSS feed feature on ticket, task, and notification worklists. This was inherently insecure as any worker could create a feed that disclosed information outside of Cerb if the URL was known. RSS feeds can be implemented in a more secure way using the Web-API or Virtual Attendant webhook behaviors.
[CHD-2422] [Workspaces/Worklists/Usability] When customizing a worklist, the process of selecting which columns to display has been drastically simplified. Previously, up to 15 dropdowns were displayed for selecting from the list of available columns. This was very cumbersome, and there was never a situation where adding the same column twice made sense. Now, all of the available columns are displayed as a list of checkboxes. Selected columns are displayed in order at the top. New columns can simply be checked and then dragged into the desired position. Additionally, this removed the arbitrary limit of 15 columns, and workers with wide screens can enable as many columns as they want.
[Workspaces/Worklists] Worklists can now provide specialized options in the customize section. For instance, the watchers column could be hidden or sorting could be disabled. Many people have asked for the ability to display dates in different ways based on the worklist (e.g. absolute or relative timestamps), and this makes implementing those feature requests very simple going forward.
[Worklists/Recommendations] On actionable worklists (e.g. tickets), a new Recommendations column is now displayed where the Watchers column was in earlier versions. For each row, a count is displayed on a button for the number of people recommended to work on that record. If the current worker has been recommended, the button will be colored green to draw their attention to it. Clicking the button displays a detailed overview of the current recommended workers, as well as the ability to add or remove recommendations.
[Worklists/Watchers/Usability] The usability of the Watchers column on all worklists has been improved. Previously, each row had a button that toggled watcher status for the current worker, and a menu provided the clunky means to add or remove watchers. Now, a button is displayed row each row with a count of the workers watching the record. If the current worker is watching the record, the button will be colored green as a visual cue. Clicking on the button now displays a detailed overview of the current watchers: status, availability, workload, and responsibility for the current bucket. This new behavior is also provided from watcher buttons on peek popups and profiles, enabling more informed decision-making.
[Worklists/Tickets/Watchers] The Watchers column can now be disabled on ticket worklists from the customize action. Previously, this was always displayed, even in environments where it didn't make sense (e.g. personal webmail).
[Worklists/Tickets/Recommendations] The new Recommendations column can be disabled on ticket worklists from the customize action.
[Workspaces/Wizard] The 'new page' wizard in workspaces now creates a mail page sorted by highest bucket responsibility, and it hides the watcher column. These defaults can be overridden from the worklist customize action.
[Workspaces/Worklists/Sorting] Custom worklists on workspaces can now be configured by the owner to prevent workers from changing the sorting on the list. This is particularly useful for ensuring a consistent team workflow (e.g. everyone is sorting by highest responsibilities + highest importance + oldest). Previously, the owner of a workspace could configure the default sorting but workers could always change it.
[Recommendations/Activity Log/Notifications] Added activity log entries and notifications for when a worker is added or removed as a recommendation on a record.
[Scheduled Behavior/Maint] Scheduled behavior entries are now properly deleted when their target record is deleted. Previously, these were cleaned up by maintenance, but they could linger for a while before then.
[Activity Log/Notifications/Usability] The Activity Log and Notifications are now more personalized with "you", "yourself", and "themselves" in place of actor names. For instance "You replied to this ticket", "You assigned yourself to this ticket", "Milo recommended you on this ticket", and "Kina recommended themselves on this ticket".
[Mail/Reply/Recommendations] The new 'Recommendations' button is now available when replying to a ticket.
[Mail/Settings/HTML] Added a worker preference for disabling the rendering of HTML messages and always showing the plaintext part instead. This can be found in the 'Mail' section from the 'Settings' page in the worker menu.
[Groups/Responsibilities/Usability] The display of per-bucket responsibilities in groups is now much more user friendly.
[Recommendations/Watchers/Responsibilities] Responsibilities now only show up on Recommendation and Watchers popups if a group/bucket is available.
- [Recommendations/Watchers] Fixed an issue where Watchers and Recommendations buttons weren't always being passed the current group/bucket for computing responsibilities.
