9
I Use This!
Inactive

News

Analyzed about 14 hours ago. based on code collected 1 day ago.
Posted over 7 years ago
Introduction Email addresses are one of the few record types that can't be deleted from within Cerb's user interface. This restriction exists to maintain referential integrity within the database -- which is a fancy way of saying that many other ... [More] records (like tickets, messages, and workers) are linked to email addresses. If these addresses were deleted then the records they are linked to would become incomplete and various features would break. Some customers have been using Cerb for the entire 12+ years of its existence. Over such a long time period, junk email addresses can create a lot of clutter when browsing address worklists. For instance, spammers often use disposable email addresses, and once those tickets and messages are deleted then the same address is never encountered again. In this situation, it's not useful to keep a record of these senders, even if they are flagged as spammers, because they won't create new messages in the future using the same identity. It is possible to delete these junk email addresses directly from the database, but this should only be done after confirming that these addresses are indeed not linked to any other important records. The script provided in this article will perform these checks automatically before removing unused addresses. Instructions Make a backup! This process will modify your database. While these instructions have been tested in many environments, it is always wise to make a backup in case something goes wrong. Install the script Download the attached cerb670_address_purge.txt script and copy it to your /cerb web directory. Rename the file to cerb670_address_purge.php Run the script This script will compile a list of email addresses from the database that are not linked to any other records. This is accomplished by making a temporary copy of the entire address book and then deleting copied records that are linked to tickets, messages, workers, etc. The remaining records are unused and can be safely deleted. This script will automatically delete those unused records. Execute the script on the command line using the php command: php cerb670_address_purge.php If addresses will be purged, the script will output: 1234 unused email addresses would be purged. To delete these unused email addresses, run the command again with the --delete argument: php cerb670_address_purge.php --delete After deleting, the script will output: Purged 1234 unused email addresses. If there are no unused email addresses, the script will output: No unused email addresses were found. Finishing up Once you have purged the unused addresses, delete the cerb670_address_purge.php script from your web server. [Less]
Posted over 8 years ago
Privacy Statement and Disclosure Webgroup Media LLC (“WGM”) is a commercial open source company that has been leading and supporting the community development of Cerb (formerly Cerberus Helpdesk) since January 2002. In connection with this business ... [More] , we operate the cerberusweb.com project website, as well as an On-Demand (“software as a service”) network of applications hosted by subscription as subdomains of cerb.me. It is WGM’s policy to respect your privacy regarding any information we may collect while operating our websites and services. We do not sell any personally identifiable information or data stored by On-Demand services to third-parties. We do not directly share your information with third-parties without explicit permission except to comply with the law or to provide necessary infrastructure in connection with the services you request; however, there is some passive risk of exposure to third-party access inherent in web-based services that is outlined in detail below. We do our best to mitigate and minimize these risks on your behalf. Website Visitors Like most website operators, WGM collects non-personally identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request. WGM’s purpose in collecting non-personally identifying information is to better understand how WGM’s visitors use its website. From time to time, WGM may release non-personally identifying information in the aggregate; e.g., by publishing a report on trends in the usage of its website. WGM also collects potentially personally identifying information like Internet Protocol (IP) addresses for website visitors and workers. WGM only discloses IP addresses under the same circumstances that it uses and discloses personally identifying information as described below. Gathering of Personally Identifying Information Certain visitors to WGM’s websites choose to interact in ways that require us to gather personally identifying information. The amount and type of information that WGM gathers depends on the nature of the interaction. For example, we ask workers who sign up for On-Demand services to provide an email address. Those who engage in financial transactions with WGM (e.g. by purchasing products and services) are asked to provide additional information, including as necessary the personal and financial information required to process those transactions. In each case, WGM collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor’s interaction with WGM. WGM does not disclose personally identifying information other than as described below. Visitors can always refuse to supply personally identifying information, with the caveat that it may prevent them from purchasing or engaging in certain services. Aggregated Statistics WGM may collect statistics about the behavior of visitors to its websites or workers of its On-Demand software. For instance, WGM may gather metrics about individual Cerb instances like the number of workers, addresses, conversations, messages, and attachments; the composition of file attachments such as distributions of sizes or file types; or the amount of activity over a given time period. This information is used to improve the usability and performance of products and services provided by WGM. WGM may display this aggregate, anonymous information publicly or provide it to others. However, WGM does not disclose personally identifying information other than as described below. Protection of Certain Personally Identifying Information WGM discloses personally identifying information only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on WGM’s behalf or to provide products and services available at WGM’s websites, and (ii) that have agreed not to disclose it to others. Some of those employees, contractors, and affiliated organizations may be located outside of your home country; and by using WGM’s websites, you consent to the transfer of such information to them. WGM will not rent or sell potentially personally identifying and personally identifying information to anyone. Other than to its employees, contractors and affiliated organizations, as described above, WGM discloses personally identifying information only in response to a subpoena, court order, or other governmental request, or when WGM believes in good faith that disclosure is reasonably necessary to protect the property or rights of WGM, third parties, or the public at large. If you are a registered user of a WGM product or service like Cerb and have supplied your email address, WGM may occasionally send you an email to tell you about new features or to solicit your feedback. We primarily use our social network profiles to communicate this type of information, and we expect to keep email broadcasts to a minimum. If you send us a request (e.g. via a support email or one of our feedback mechanisms), we reserve the right to anonymously republish it in order to help us clarify or respond to your request, or to help us support other users. WGM takes all measures reasonably necessary to protect against the unauthorized access, use, alteration or destruction of potentially personally identifying information. Security and Safeguards WGM takes reasonable precautions to protect your data and personally identifying information. We do not have physical access to any of our servers or online storage mediums. See the section about “Third-Party Data Centers” for the upstream security policies of SoftLayer, Amazon Web Services, and Linode. These servers are protected within state-of-the-art data centers. WGM performs 24/7/365 monitoring of our network and service infrastructure. This includes metrics like server load, process information, account access, service utilization, and network activity. Web-based communication with our servers is protected through 256-bit encryption via Secure Socket Layer (SSL) technology. This feature is included with all On-Demand applications when URLs are prefixed with “https://”. It is the responsibility of clients and their representatives to ensure the use of SSL; and upon request we can configure your application to require the use of SSL. We do not store credit card information on our servers. For one-time transactions we do not save credit card or bank account numbers anywhere, although we do store email-based receipts that include contact information, payment type, transaction IDs, and authorization codes. For recurring transactions, payment information is stored with vendors who adhere to the Payment Card Industry Data Security Standards (PCI DSS). We use FreshBooks for sending invoices and collecting payments, and they protect financial information with AES encryption. We process credit card transactions through our merchant account at Authorize.net. Depending on a client’s preferred payment method, these transactions may alternatively take place through other vendors like PayPal, or through wire transfers to Wells Fargo Bank. We do not have access to client credit card numbers or bank account information through any of these vendors. WGM technicians securely access our servers using Secure Shell (SSH) encryption. Logins are authenticated with RSA keys rather than simple passwords. We do not provide general purpose client access (e.g. SSH, Telnet, FTP) to machines housing multi-tenant On-Demand data. We have disabled insecure features in our PHP environment (e.g. process control, shell command execution, remote file includes) to protect against arbitrary code execution. To protect against cross-site scripting (XSS), we “escape” all user-provided data that is displayed in a web browser. Disclosure of Security Breaches WGM will notify you as soon as possible if a security breach results in the potential disclosure of any personally identifiable information or data related to your account. At the conclusion of a security investigation, WGM will provide you with a report about the nature of any compromised data (e.g. email addresses, worker account passwords) and the actions taken to prevent future intrusions. Third-Party Data Centers, Cloud Computing, and Virtualization WGM remotely provisions, administers, and maintains servers in various data centers throughout the world and WGM does not maintain a physical presence in any of them. Most On-Demand services are currently provided from machines exclusively leased and operated by WGM from SoftLayer in their Seattle and Dallas facilities. However, other services, like our project portal, are provided from virtual servers in cloud computing and storage environments at Amazon Web Services and Linode. In virtual environments, many users from various organizations share a pool of resources like computational power and storage capacity, although provisioned resources are isolated from one another to a similar degree as leased machines in a datacenter. Due to the remote nature of leased servers, colocation, cloud computing, and virtualization, authorized technicians from our vendors and service providers may have temporary access to our servers in order to perform physical maintenance and upgrades, or to provide hands-on assistance with troubleshooting issues like RAID degradation and hardware failures. In such events we defer to upstream privacy policies: http://www.softlayer.com/privacy-agreement http://aws.amazon.com/privacy/ https://www.linode.com/privacy Backups Cerb has two main components for storing customer data: (1) the database, and (2) the /storage/ filesystem which contains large, immutable content like email attachments. Data may be stored on a single machine, or distributed among several machines, on our On-Demand network. Generally, that data will be housed on WGM’s dedicated servers in SoftLayer’s datacenters. If you communicate with WGM, or use On-Demand services provided by WGM, your information will be regularly copied for the express purpose of maintaining backups for continuity and disaster recovery. Nightly backups and redundant storage are kept on machines controlled remotely by WGM. Backups may be transferred to Amazon’s Simple Storage Service (S3) for long-term, off-site archival. When WGM runs nightly backups, we make full backups of the database, and incremental backups of the /storage/ filesystem. These are stored in the same datacenter, and are often attached to the same server, but on an alternate, redundant storage medium. Twice per week (usually Wednesday and Sunday) we off-site the latest backups to our private buckets on Amazon’s S3 service. We also rotate these to keep a weekly backup for a few months of history, and at least the most recent three backups. Disposal of Data and Backups Upon cancellation, we remove all client data from the On-Demand network and send a final backup to Amazon S3. We will attempt to make arrangements for this backup to be transferred to the client before permanently destroying our copies of the data. Without an explicit request for their immediate removal, backups may be persisted for several months. We will comply with any written, and duly authenticated, client requests for the immediate destruction of all account data and backups. Testimonials WGM displays a list of clients and testimonials on our websites. We do not disclose the names of licensed organizations, or their representatives, without explicit permission, except in the event that a client freely discloses their identity through postings on public forums or social networks. Cookies A cookie is a string of information that a website stores on a visitor’s computer, and that the visitor’s browser provides to the website each time the visitor returns. WGM uses cookies to help WGM identify and track visitors, their usage of WGM website, and their website access preferences. Visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using WGM’s websites, with the drawback that certain features of WGM’s websites may not function properly without the aid of cookies. Web-based products like Cerb require cookies to be enabled, although their use is limited to maintaining a logged-in session within the software. Business Transfers If WGM, or substantially all of its assets were acquired, or in the unlikely event that WGM goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of WGM may continue to use your personal information as set forth in this policy. Ads In the rare event that ads appear in any of our applications or on any of our websites, they may be delivered to users by advertising partners, who may set cookies. These cookies allow the ad server to recognize your computer each time they send you an online advertisement to compile information about you or others who use your computer. This information allows ad networks to, among other things, deliver targeted advertisements that they believe will be of most interest to you. This Privacy Policy covers the use of cookies by WGM and does not cover the use of cookies by any advertisers. Privacy Policy Changes Although most changes are likely to be minor, WGM may change its Privacy Policy from time to time, and in WGM’s sole discretion. WGM encourages visitors to frequently check this page for any changes to its Privacy Policy. Your continued use of this site after any change in this Privacy Policy will constitute your acceptance of such change. License This privacy policy is available under a Creative Commons Sharealike license derived from original groundwork by Automattic. WGM has no professional affiliation with Automattic. [Less]
Posted over 8 years ago
Privacy Statement and Disclosure Webgroup Media LLC (“WGM”) is a commercial open source company that has been leading and supporting the community development of Cerb (formerly Cerberus Helpdesk) since January 2002. In connection with this business ... [More] , we operate the cerberusweb.com project website, as well as an On-Demand (“software as a service”) network of applications hosted by subscription as subdomains of cerb.me. It is WGM’s policy to respect your privacy regarding any information we may collect while operating our websites and services. We do not sell any personally identifiable information or data stored by On-Demand services to third-parties. We do not directly share your information with third-parties without explicit permission except to comply with the law or to provide necessary infrastructure in connection with the services you request; however, there is some passive risk of exposure to third-party access inherent in web-based services that is outlined in detail below. We do our best to mitigate and minimize these risks on your behalf. Website Visitors Like most website operators, WGM collects non-personally identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request. WGM’s purpose in collecting non-personally identifying information is to better understand how WGM’s visitors use its website. From time to time, WGM may release non-personally identifying information in the aggregate; e.g., by publishing a report on trends in the usage of its website. WGM also collects potentially personally identifying information like Internet Protocol (IP) addresses for website visitors and workers. WGM only discloses IP addresses under the same circumstances that it uses and discloses personally identifying information as described below. Gathering of Personally Identifying Information Certain visitors to WGM’s websites choose to interact in ways that require us to gather personally identifying information. The amount and type of information that WGM gathers depends on the nature of the interaction. For example, we ask workers who sign up for On-Demand services to provide an email address. Those who engage in financial transactions with WGM (e.g. by purchasing products and services) are asked to provide additional information, including as necessary the personal and financial information required to process those transactions. In each case, WGM collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor’s interaction with WGM. WGM does not disclose personally identifying information other than as described below. Visitors can always refuse to supply personally identifying information, with the caveat that it may prevent them from purchasing or engaging in certain services. Aggregated Statistics WGM may collect statistics about the behavior of visitors to its websites or workers of its On-Demand software. For instance, WGM may gather metrics about individual Cerb instances like the number of workers, addresses, conversations, messages, and attachments; the composition of file attachments such as distributions of sizes or file types; or the amount of activity over a given time period. This information is used to improve the usability and performance of products and services provided by WGM. WGM may display this aggregate, anonymous information publicly or provide it to others. However, WGM does not disclose personally identifying information other than as described below. Protection of Certain Personally Identifying Information WGM discloses personally identifying information only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on WGM’s behalf or to provide products and services available at WGM’s websites, and (ii) that have agreed not to disclose it to others. Some of those employees, contractors, and affiliated organizations may be located outside of your home country; and by using WGM’s websites, you consent to the transfer of such information to them. WGM will not rent or sell potentially personally identifying and personally identifying information to anyone. Other than to its employees, contractors and affiliated organizations, as described above, WGM discloses personally identifying information only in response to a subpoena, court order, or other governmental request, or when WGM believes in good faith that disclosure is reasonably necessary to protect the property or rights of WGM, third parties, or the public at large. If you are a registered user of a WGM product or service like Cerb and have supplied your email address, WGM may occasionally send you an email to tell you about new features or to solicit your feedback. We primarily use our social network profiles to communicate this type of information, and we expect to keep email broadcasts to a minimum. If you send us a request (e.g. via a support email or one of our feedback mechanisms), we reserve the right to anonymously republish it in order to help us clarify or respond to your request, or to help us support other users. WGM takes all measures reasonably necessary to protect against the unauthorized access, use, alteration or destruction of potentially personally identifying information. Security and Safeguards WGM takes reasonable precautions to protect your data and personally identifying information. We do not have physical access to any of our servers or online storage mediums. See the section about “Third-Party Data Centers” for the upstream security policies of SoftLayer, Amazon Web Services, and Linode. These servers are protected within state-of-the-art data centers. WGM performs 24/7/365 monitoring of our network and service infrastructure. This includes metrics like server load, process information, account access, service utilization, and network activity. Web-based communication with our servers is protected through 256-bit encryption via Secure Socket Layer (SSL) technology. This feature is included with all On-Demand applications when URLs are prefixed with “https://”. It is the responsibility of clients and their representatives to ensure the use of SSL; and upon request we can configure your application to require the use of SSL. We do not store credit card information on our servers. For one-time transactions we do not save credit card or bank account numbers anywhere, although we do store email-based receipts that include contact information, payment type, transaction IDs, and authorization codes. For recurring transactions, payment information is stored with vendors who adhere to the Payment Card Industry Data Security Standards (PCI DSS). We use FreshBooks for sending invoices and collecting payments, and they protect financial information with AES encryption. We process credit card transactions through our merchant account at Authorize.net. Depending on a client’s preferred payment method, these transactions may alternatively take place through other vendors like PayPal, or through wire transfers to Wells Fargo Bank. We do not have access to client credit card numbers or bank account information through any of these vendors. WGM technicians securely access our servers using Secure Shell (SSH) encryption. Logins are authenticated with RSA keys rather than simple passwords. We do not provide general purpose client access (e.g. SSH, Telnet, FTP) to machines housing multi-tenant On-Demand data. We have disabled insecure features in our PHP environment (e.g. process control, shell command execution, remote file includes) to protect against arbitrary code execution. To protect against cross-site scripting (XSS), we “escape” all user-provided data that is displayed in a web browser. Disclosure of Security Breaches WGM will notify you as soon as possible if a security breach results in the potential disclosure of any personally identifiable information or data related to your account. At the conclusion of a security investigation, WGM will provide you with a report about the nature of any compromised data (e.g. email addresses, worker account passwords) and the actions taken to prevent future intrusions. Third-Party Data Centers, Cloud Computing, and Virtualization WGM remotely provisions, administers, and maintains servers in various data centers throughout the world and WGM does not maintain a physical presence in any of them. Most On-Demand services are currently provided from machines exclusively leased and operated by WGM from SoftLayer in their Seattle and Dallas facilities. However, other services, like our project portal, are provided from virtual servers in cloud computing and storage environments at Amazon Web Services and Linode. In virtual environments, many users from various organizations share a pool of resources like computational power and storage capacity, although provisioned resources are isolated from one another to a similar degree as leased machines in a datacenter. Due to the remote nature of leased servers, colocation, cloud computing, and virtualization, authorized technicians from our vendors and service providers may have temporary access to our servers in order to perform physical maintenance and upgrades, or to provide hands-on assistance with troubleshooting issues like RAID degradation and hardware failures. In such events we defer to upstream privacy policies: http://www.softlayer.com/privacy-agreement http://aws.amazon.com/privacy/ https://www.linode.com/privacy Backups Cerb has two main components for storing customer data: (1) the database, and (2) the /storage/ filesystem which contains large, immutable content like email attachments. Data may be stored on a single machine, or distributed among several machines, on our On-Demand network. Generally, that data will be housed on WGM’s dedicated servers in SoftLayer’s datacenters. If you communicate with WGM, or use On-Demand services provided by WGM, your information will be regularly copied for the express purpose of maintaining backups for continuity and disaster recovery. Nightly backups and redundant storage are kept on machines controlled remotely by WGM. Backups may be transferred to Amazon’s Simple Storage Service (S3) for long-term, off-site archival. When WGM runs nightly backups, we make full backups of the database, and incremental backups of the /storage/ filesystem. These are stored in the same datacenter, and are often attached to the same server, but on an alternate, redundant storage medium. Twice per week (usually Wednesday and Sunday) we off-site the latest backups to our private buckets on Amazon’s S3 service. We also rotate these to keep a weekly backup for a few months of history, and at least the most recent three backups. Disposal of Data and Backups Upon cancellation, we remove all client data from the On-Demand network and send a final backup to Amazon S3. We will attempt to make arrangements for this backup to be transferred to the client before permanently destroying our copies of the data. Without an explicit request for their immediate removal, backups may be persisted for several months. We will comply with any written, and duly authenticated, client requests for the immediate destruction of all account data and backups. Testimonials WGM displays a list of clients and testimonials on our websites. We do not disclose the names of licensed organizations, or their representatives, without explicit permission, except in the event that a client freely discloses their identity through postings on public forums or social networks. Cookies A cookie is a string of information that a website stores on a visitor’s computer, and that the visitor’s browser provides to the website each time the visitor returns. WGM uses cookies to help WGM identify and track visitors, their usage of WGM website, and their website access preferences. Visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using WGM’s websites, with the drawback that certain features of WGM’s websites may not function properly without the aid of cookies. Web-based products like Cerb require cookies to be enabled, although their use is limited to maintaining a logged-in session within the software. Business Transfers If WGM, or substantially all of its assets were acquired, or in the unlikely event that WGM goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of WGM may continue to use your personal information as set forth in this policy. Ads In the rare event that ads appear in any of our applications or on any of our websites, they may be delivered to users by advertising partners, who may set cookies. These cookies allow the ad server to recognize your computer each time they send you an online advertisement to compile information about you or others who use your computer. This information allows ad networks to, among other things, deliver targeted advertisements that they believe will be of most interest to you. This Privacy Policy covers the use of cookies by WGM and does not cover the use of cookies by any advertisers. Privacy Policy Changes Although most changes are likely to be minor, WGM may change its Privacy Policy from time to time, and in WGM’s sole discretion. WGM encourages visitors to frequently check this page for any changes to its Privacy Policy. Your continued use of this site after any change in this Privacy Policy will constitute your acceptance of such change. License This privacy policy is available under a Creative Commons Sharealike license derived from original groundwork by Automattic. WGM has no professional affiliation with Automattic. [Less]
Posted over 8 years ago
Privacy Statement and Disclosure Webgroup Media LLC (“WGM”) is a commercial open source company that has been leading and supporting the community development of Cerb (formerly Cerberus Helpdesk) since January 2002. In connection with this business ... [More] , we operate the cerberusweb.com project website, as well as an On-Demand (“software as a service”) network of applications hosted by subscription as subdomains of cerb.me. It is WGM’s policy to respect your privacy regarding any information we may collect while operating our websites and services. We do not sell any personally identifiable information or data stored by On-Demand services to third-parties. We do not directly share your information with third-parties without explicit permission except to comply with the law or to provide necessary infrastructure in connection with the services you request; however, there is some passive risk of exposure to third-party access inherent in web-based services that is outlined in detail below. We do our best to mitigate and minimize these risks on your behalf. Website Visitors Like most website operators, WGM collects non-personally identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request. WGM’s purpose in collecting non-personally identifying information is to better understand how WGM’s visitors use its website. From time to time, WGM may release non-personally identifying information in the aggregate; e.g., by publishing a report on trends in the usage of its website. WGM also collects potentially personally identifying information like Internet Protocol (IP) addresses for website visitors and workers. WGM only discloses IP addresses under the same circumstances that it uses and discloses personally identifying information as described below. Gathering of Personally Identifying Information Certain visitors to WGM’s websites choose to interact in ways that require us to gather personally identifying information. The amount and type of information that WGM gathers depends on the nature of the interaction. For example, we ask workers who sign up for On-Demand services to provide an email address. Those who engage in financial transactions with WGM (e.g. by purchasing products and services) are asked to provide additional information, including as necessary the personal and financial information required to process those transactions. In each case, WGM collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor’s interaction with WGM. WGM does not disclose personally identifying information other than as described below. Visitors can always refuse to supply personally identifying information, with the caveat that it may prevent them from purchasing or engaging in certain services. Aggregated Statistics WGM may collect statistics about the behavior of visitors to its websites or workers of its On-Demand software. For instance, WGM may gather metrics about individual Cerb instances like the number of workers, addresses, conversations, messages, and attachments; the composition of file attachments such as distributions of sizes or file types; or the amount of activity over a given time period. This information is used to improve the usability and performance of products and services provided by WGM. WGM may display this aggregate, anonymous information publicly or provide it to others. However, WGM does not disclose personally identifying information other than as described below. Protection of Certain Personally Identifying Information WGM discloses personally identifying information only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on WGM’s behalf or to provide products and services available at WGM’s websites, and (ii) that have agreed not to disclose it to others. Some of those employees, contractors, and affiliated organizations may be located outside of your home country; and by using WGM’s websites, you consent to the transfer of such information to them. WGM will not rent or sell potentially personally identifying and personally identifying information to anyone. Other than to its employees, contractors and affiliated organizations, as described above, WGM discloses personally identifying information only in response to a subpoena, court order, or other governmental request, or when WGM believes in good faith that disclosure is reasonably necessary to protect the property or rights of WGM, third parties, or the public at large. If you are a registered user of a WGM product or service like Cerb and have supplied your email address, WGM may occasionally send you an email to tell you about new features or to solicit your feedback. We primarily use our social network profiles to communicate this type of information, and we expect to keep email broadcasts to a minimum. If you send us a request (e.g. via a support email or one of our feedback mechanisms), we reserve the right to anonymously republish it in order to help us clarify or respond to your request, or to help us support other users. WGM takes all measures reasonably necessary to protect against the unauthorized access, use, alteration or destruction of potentially personally identifying information. Security and Safeguards WGM takes reasonable precautions to protect your data and personally identifying information. We do not have physical access to any of our servers or online storage mediums. See the section about “Third-Party Data Centers” for the upstream security policies of SoftLayer, Amazon Web Services, and Linode. These servers are protected within state-of-the-art data centers. WGM performs 24/7/365 monitoring of our network and service infrastructure. This includes metrics like server load, process information, account access, service utilization, and network activity. Web-based communication with our servers is protected through 256-bit encryption via Secure Socket Layer (SSL) technology. This feature is included with all On-Demand applications when URLs are prefixed with “https://”. It is the responsibility of clients and their representatives to ensure the use of SSL; and upon request we can configure your application to require the use of SSL. We do not store credit card information on our servers. For one-time transactions we do not save credit card or bank account numbers anywhere, although we do store email-based receipts that include contact information, payment type, transaction IDs, and authorization codes. For recurring transactions, payment information is stored with vendors who adhere to the Payment Card Industry Data Security Standards (PCI DSS). We use FreshBooks for sending invoices and collecting payments, and they protect financial information with AES encryption. We process credit card transactions through our merchant account at Authorize.net. Depending on a client’s preferred payment method, these transactions may alternatively take place through other vendors like PayPal, or through wire transfers to Wells Fargo Bank. We do not have access to client credit card numbers or bank account information through any of these vendors. WGM technicians securely access our servers using Secure Shell (SSH) encryption. Logins are authenticated with RSA keys rather than simple passwords. We do not provide general purpose client access (e.g. SSH, Telnet, FTP) to machines housing multi-tenant On-Demand data. We have disabled insecure features in our PHP environment (e.g. process control, shell command execution, remote file includes) to protect against arbitrary code execution. To protect against cross-site scripting (XSS), we “escape” all user-provided data that is displayed in a web browser. Disclosure of Security Breaches WGM will notify you as soon as possible if a security breach results in the potential disclosure of any personally identifiable information or data related to your account. At the conclusion of a security investigation, WGM will provide you with a report about the nature of any compromised data (e.g. email addresses, worker account passwords) and the actions taken to prevent future intrusions. Third-Party Data Centers, Cloud Computing, and Virtualization WGM remotely provisions, administers, and maintains servers in various data centers throughout the world and WGM does not maintain a physical presence in any of them. Most On-Demand services are currently provided from machines exclusively leased and operated by WGM from SoftLayer in their Seattle and Dallas facilities. However, other services, like our project portal, are provided from virtual servers in cloud computing and storage environments at Amazon Web Services and Linode. In virtual environments, many users from various organizations share a pool of resources like computational power and storage capacity, although provisioned resources are isolated from one another to a similar degree as leased machines in a datacenter. Due to the remote nature of leased servers, colocation, cloud computing, and virtualization, authorized technicians from our vendors and service providers may have temporary access to our servers in order to perform physical maintenance and upgrades, or to provide hands-on assistance with troubleshooting issues like RAID degradation and hardware failures. In such events we defer to upstream privacy policies: http://www.softlayer.com/privacy-agreement http://aws.amazon.com/privacy/ https://www.linode.com/privacy Backups Cerb has two main components for storing customer data: (1) the database, and (2) the /storage/ filesystem which contains large, immutable content like email attachments. Data may be stored on a single machine, or distributed among several machines, on our On-Demand network. Generally, that data will be housed on WGM’s dedicated servers in SoftLayer’s datacenters. If you communicate with WGM, or use On-Demand services provided by WGM, your information will be regularly copied for the express purpose of maintaining backups for continuity and disaster recovery. Nightly backups and redundant storage are kept on machines controlled remotely by WGM. Backups may be transferred to Amazon’s Simple Storage Service (S3) for long-term, off-site archival. When WGM runs nightly backups, we make full backups of the database, and incremental backups of the /storage/ filesystem. These are stored in the same datacenter, and are often attached to the same server, but on an alternate, redundant storage medium. Twice per week (usually Wednesday and Sunday) we off-site the latest backups to our private buckets on Amazon’s S3 service. We also rotate these to keep a weekly backup for a few months of history, and at least the most recent three backups. Disposal of Data and Backups Upon cancellation, we remove all client data from the On-Demand network and send a final backup to Amazon S3. We will attempt to make arrangements for this backup to be transferred to the client before permanently destroying our copies of the data. Without an explicit request for their immediate removal, backups may be persisted for several months. We will comply with any written, and duly authenticated, client requests for the immediate destruction of all account data and backups. Testimonials WGM displays a list of clients and testimonials on our websites. We do not disclose the names of licensed organizations, or their representatives, without explicit permission, except in the event that a client freely discloses their identity through postings on public forums or social networks. Cookies A cookie is a string of information that a website stores on a visitor’s computer, and that the visitor’s browser provides to the website each time the visitor returns. WGM uses cookies to help WGM identify and track visitors, their usage of WGM website, and their website access preferences. Visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using WGM’s websites, with the drawback that certain features of WGM’s websites may not function properly without the aid of cookies. Web-based products like Cerb require cookies to be enabled, although their use is limited to maintaining a logged-in session within the software. Business Transfers If WGM, or substantially all of its assets were acquired, or in the unlikely event that WGM goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of WGM may continue to use your personal information as set forth in this policy. Ads In the rare event that ads appear in any of our applications or on any of our websites, they may be delivered to users by advertising partners, who may set cookies. These cookies allow the ad server to recognize your computer each time they send you an online advertisement to compile information about you or others who use your computer. This information allows ad networks to, among other things, deliver targeted advertisements that they believe will be of most interest to you. This Privacy Policy covers the use of cookies by WGM and does not cover the use of cookies by any advertisers. Privacy Policy Changes Although most changes are likely to be minor, WGM may change its Privacy Policy from time to time, and in WGM’s sole discretion. WGM encourages visitors to frequently check this page for any changes to its Privacy Policy. Your continued use of this site after any change in this Privacy Policy will constitute your acceptance of such change. License This privacy policy is available under a Creative Commons Sharealike license derived from original groundwork by Automattic. WGM has no professional affiliation with Automattic. [Less]
Posted almost 9 years ago
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 ... [More] [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. [Less]
Posted almost 9 years ago
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 ... [More] [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. [Less]
Posted almost 9 years ago
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 ... [More] [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. [Less]
Posted about 9 years ago
If you'd like to prevent tickets from getting assigned and then ignored, this should do the trick for you. First, you'll create (import) a custom ticket behavior to simply set the owner to 'nobody', then you'll create a custom worker behavior that ... [More] will search for those idle tickets (perhaps daily). To start, download the Unassign Ticket VA.txt file. Go to your Virtual Attendant area (click on your name in the top right, then click on Virtual Attendants, then click on the one for you) 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. We'll need to identify the internal ID of that behavior (to use in the next step), so right-click on the 'Custom ticket behavior' bubble and select 'Inspect element'. The highlighted text will indicate a "trigger_id"; make a note of this number. Next, download the Find Assigned Idle Tickets VA.txt file. Import this one as well, but before you save it, you'll need to modify the ID of the called behavior. In the provided VA, the ID of the Unassign Tickets behavior is seen at the bottom, in "behavior_id":"29". Replace that with the ID of the behavior you created in step one, and save this one. To schedule this behavior to repeat every morning, 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 "Unassign idle tickets" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. [Less]
Posted about 9 years ago
If you'd like to prevent tickets from getting assigned and then ignored, this should do the trick for you. First, you'll create (import) a custom ticket behavior to simply set the owner to 'nobody', then you'll create a custom worker behavior that ... [More] will search for those idle tickets (perhaps daily). To start, download the Unassign Ticket VA.txt file. Go to your Virtual Attendant area (click on your name in the top right, then click on Virtual Attendants, then click on the one for you) 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. We'll need to identify the internal ID of that behavior (to use in the next step), so right-click on the 'Custom ticket behavior' bubble and select 'Inspect element'. The highlighted text will indicate a "trigger_id"; make a note of this number. Next, download the Find Assigned Idle Tickets VA.txt file. Import this one as well, but before you save it, you'll need to modify the ID of the called behavior. In the provided VA, the ID of the Unassign Tickets behavior is seen at the bottom, in "behavior_id":"29". Replace that with the ID of the behavior you created in step one, and save this one. To schedule this behavior to repeat every morning, 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 "Unassign idle tickets" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. [Less]
Posted about 9 years ago
If you'd like to prevent tickets from getting assigned and then ignored, this should do the trick for you. First, you'll create (import) a custom ticket behavior to simply set the owner to 'nobody', then you'll create a custom worker behavior that ... [More] will search for those idle tickets (perhaps daily). To start, download the Unassign Ticket VA.txt file. Go to your Virtual Attendant area (click on your name in the top right, then click on Virtual Attendants, then click on the one for you) 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. We'll need to identify the internal ID of that behavior (to use in the next step), so right-click on the 'Custom ticket behavior' bubble and select 'Inspect element'. The highlighted text will indicate a "trigger_id"; make a note of this number. Next, download the Find Assigned Idle Tickets VA.txt file. Import this one as well, but before you save it, you'll need to modify the ID of the called behavior. In the provided VA, the ID of the Unassign Tickets behavior is seen at the bottom, in "behavior_id":"29". Replace that with the ID of the behavior you created in step one, and save this one. To schedule this behavior to repeat every morning, 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 "Unassign idle tickets" VA, enter "tomorrow 8am" as the time when the behavior should happen, and select repeat "every" 24 hours. [Less]