New Features

• Case Portal: Enable community members to close their own cases
• New notification setting options
• Category Subscriptions
• Performance improvements for communities using a Responsive-based skin (Early Access)
• Spam Quarantine alert messages for Idea boards
• Updates for referencing metrics components within other components
• Updates to SSO PHP and Java libraries
• New version (1.6.0) of the Community Plugin SDK is available
• New Khoros Developer Doc Portal
• API changes

Case Portal: Enable community members to close their own cases

Ability for members to close own cases

Sometimes, your Customer Support team might solve a customer’s issue but not know it because the customer neglected or forgot to respond back on the ticket. As a result, tickets might stay open longer than needed. One way to mitigate this from happening is to enable customers to close their own cases directly from your community’s Case Portal, where they received the response that solved their problem.

Note: To have the Close Case feature enabled for your Community, open a Support ticket.

Enabling community members to close their own cases from the Case Portal involves these tasks:

• Set up your Close Case form field options
• Grant members the ability to close Case Portal cases

Set up Close Case form field options

To define your Case Portal close case fields:

1. Sign in to the community as an Admin.
2. Go to Admin > Features > Case Portal.
   
   
3. In the Close Case form Status field options, enter a comma-separated list of values for the Close As status field. These entries must match entries in your CRM.
   
   
4. In the Close Case form Comment field options, enter a comma-separated list of values for the Comments status field. These values can be anything you want to reflect close reasons you want to measure; for example, “Found my answer” or “Agent fixed my issue”.
   
5. Click Save.

Grant members the ability to close Case Portal cases

For members to be able to close Case Portal cases themselves, they must be granted permission to do so. By default, this permission is denied to all members.

To enable all community members to close their own support cases via the Case Portal:

1. Sign in to the community as an Admin.
2. Go to Admin > Users > Permissions.
3. Scroll down to Case Portal section.
4. Grant the Allow members to close their own Support cases from Case Portal permission.
   
   

Note: You can also grant this ability to specific members or roles by editing the role’s or user’s permissions directly.

See it in action

Now, when permissioned users want visit their Case Portal page, they have the option to close any of their open cases. When the member selects an open case from their Case Portal page, a Close case button appears on the Case Details page:

The member can then select the appropriate Status and Close Comments options (as defined in above in the previous procedure) and click Save to close the case.

Learn more about Case Portal.

New notification setting options

We have added several new notification settings to give users more control over which email, real-time, and mobile notifications they receive.

New notification settings include:

• Turn off all push notifications: When selected, no push notifications (email, mobile, or real-time pop-up messages) are sent to you. Notifications still appear in the Notification Feed.
• Turn off all email notifications: When selected, no email notifications are sent to you. Notifications still appear in the Notification Feed.
• Turn off all real-time pop-up notifications: When selected, no real-time pop-up messages are sent to you. Notifications still appear in the Notification Feed.
• Turn off all mobile notifications: When selected, no mobile notifications are sent to you. Notifications still appear in the Notification Feed.

To set your notification options:

1. Sign in to the community.
2. Click your profile avatar/name to open the drop-down menu.
   
   
3. Click My Settings.
4. Go to Subscriptions & Notifications > Notification Settings.
5. Set the global notifications options (defined above):
   
   
6. Click Save.

Additionally, Admins can set the default notification options for all users (which users can override as described above) as follows:

1. Sign in to the community as an Admin.
2. Go to Users > Notification Defaults.
3. Set the global notifications options (defined above):
   admin notification defaults page
   
4. Click Save.

Note: Admins can globally control default settings for either all push notifications together (email, real-time pop-up, and mobile) or separately for real-time pop-up and mobile. Currently, it’s not possible for Admins to control just the email notifications alone, by default. Members control this via their personal settings, as described above.

Category Subscriptions

Your customers can now subscribe to categories. They can choose to subscribe to all nodes in the category, subcategories, or just the boards they are interested in.

Category Subscriptions requires Category feature version 2.1.

Users can subscribe from the Options menu or from a link generated by the categories.widget.add-category-user-email component. (See Add a Subscribe or Edit Subscription Link later in this section for instructions.)

Note: The Options menu is generated by the Page Options component (community.widget.page-options). By default, this component appears in the Header quilt. In XML view, the component looks like this: <component id="community.widget.page-options"/>.  If you do not see the Options menu on your Category page, you can add the component in XML view or add the Page Options component from the Components area of the Page tab. Find the component under the Page Elements category. If your Category page has the Page Options component, but you do not see the Subscribe/Unsubscribe options, your Options menu has likely been customized by Services or a Khoros partner. In this case, a Services engagement will be required to add the Subscribe/Unsubscribe option to the menu.

When the customer selects the Subscribe option, the customer chooses which nodes in the category to include in the subscription.

Category subscription notifications are included in the General Subscription Notification and Digest Subscription Notification email templates.  

Customers manage category subscriptions in the My Subscriptions tab under My Settings > Subscriptions & Notifications.

Selecting the subscription in the My Subscriptions tab opens the Edit Category Subscription modal where they can change the boards included in the subscription or delete the category subscription entirely.

Add a Subscribe or Edit Subscription link

You can also enable a user to subscribe to a category with the categories.widget.add-category-user-email component. This component creates a link that reads Subscribe or Edit Subscription, depending on the user’s subscription state. Selecting the link opens the subscription modal.

You can use the categories.widget.add-category-user-email component on a Category page only.

To add the categories.widget.add-category-user-email component to a Category Page, add the following to the quilt XML in the desired location:

<component id="categories.widget.add-category-user-email"/>

Performance improvements for communities using a Responsive-based skin (Early Access)

We have improved the overall performance and page-load speeds for communities using Responsive or a Responsive-based skin.

With these improvements, only the CSS necessary to render each page type is loaded, as opposed to loading the complete website CSS for any page.

To enable these CSS performance improvements, open a Support ticket.

Spam Quarantine alert message for Idea boards

Topic and reply posts marked as spam in Idea boards now display a yellow, visual alert message to Community users when they come to a post that has been marked as spam via a permalink, say in a Community email digest or in a source from outside the community.

Example alert banner message for a new Idea marked as spam:

Example of what your Admin sees when visiting a page for an Idea marked as spam:

This functionality is enabled by default, and no action is required by you.

Learn more about Spam Quarantine alert messages in the community.

Updates for referencing metrics components within other components

The Community Metrics and User Statistics components use the li-metric-name parameter to define to specify which metric to display in the component. (See Configure the Community Metrics and User Statistics components  for details.)

In previous releases, some customers successfully used unofficially supported versions of the li-metric-name parameter in customizations:

• li_metric_name
• metricName

This often occurred in customizations where the community.widget.metrics-display component was referenced in a custom component using the @component FreeMarker directive.

As of 19.5, the only allowed way to specify which metric to use is li-metric-name.

Important: When passing the li-metric name in a custom component using @component, you must escpape 'li-metric-name' like this: li\-metric\-name. Otherwise, you will receive this FreeMarker error:

Freemarker template 'preview' parsing failed:
ParseException:Syntax error in template "preview" in line 1, column 70:
Encountered "-", but was expecting: "="

Updates to SSO PHP and Java libraries

We have added support for PHP 7.2 to our PHP SSO Client. Part of the upgrade to our PHP SSO client removes the deprecated mcrypt library calls. We have a new version of the SSO Guide and we have updated PHP and Java library downloads. 

See About Khoros Single Sign-On (SSO) for details and downloads. 

Version 1.6.0 of the Community Plugin SDK

We have released version 1.6.0 of the Community Plugin SDK. This new version includes language support for Latvian. To update your Community SDK plugin, run npm update -g lithium-sdk and then li update-project, as described in Update the SDK Plugin.

New Khoros Developer Doc Portal

We’re excited to announce the launch of our new Khoros Developer Documentation Portal on its very own domain: developer.khoros.com.

We’ve migrated the Khoros Communities and Khoros Care developer content and the articles from the Developer Knowledge Base into our new portal. The Developer Knowledge Base will be around for a couple more weeks, and then we will be archiving the articles.

The Developer Discussion forum is staying right where it is today in the Khoros Community. We link to the Developer Discussion forum at the top of the new Developer Documentation Portal, so the Khoros Community is always just a click away.

Over the first few months, expect to see iterative improvements as we polish some areas and work out the kinks in others. In the meantime, we’d love to hear your feedback.

Learn more about the new Khoros Developer Doc Portal.

API changes

Community API v2

Changes to counts returned by queries sorted by kudos.sum(weight), replies.count(*), and metrics.views

LiQL queries to the Messages collection sorted by kudos.sum(weight), replies.count(*), and metrics.views in the ORDER BY clause now consistently sort the results by and return values for the metrics.views, replies.count, and kudos.sum.weight fields based on data in the search index rather than in the database. We made this change because queries using these fields in the ORDER BY clause were ordered based on the search index, but the values shown for the fields were pulled from the database, causing confusion to customers.

Examples of these queries include:

SELECT id, metrics FROM messages ORDER BY metrics.views DESC
SELECT id, kudos.sum.(weight) FROM messages ORDER BY kudos.sum.(weight) DESC
SELECT id, replies.count(*) FROM messages WHERE depth = 0 ORDER BY replies.count(*) DESC

If a LiQL query does not sort queries to the Messages collection by metrics.views, replies.count(*), and kudos.sum(weight) in the ORDER BY clause, then the values of the metrics.views, replies.count, and kudos.sum.weight fields are based on the values in the database.

Examples of these queries include:

SELECT id, metrics FROM messages
SELECT id, kudos.sum.(weight) FROM messages
SELECT id, replies.count(*) FROM messages WHERE depth = 0

This means that you will see different results if you compare a query like

SELECT id, metrics FROM messages ORDER BY metrics.views DESC

against a query like

SELECT id, metrics FROM message

Values returned from the database will represent the latest metrics views, kudos count, and replies count. Values returned from the search index will be based on the latest index generated, which could be different from the latest value in the database. Be sure to take this difference into consideration when writing your customizations using these kinds of queries.

Updates to the Ranks collection

You can now constrain queries to the Ranks collection by the name and id fields. Supported operators: =, IN()

We’ve added a new field called rank_status on the Rank object. Supported statuses: active, deleted.

You can constrain queries to the Ranks collection by rank_status.

Examples

SELECT id FROM ranks WHERE rank_status='deleted'
SELECT id FROM ranks WHERE rank_status='active'
SELECT name FROM ranks WHERE id = '4'
SELECT name FROM ranks WHERE id IN ('23','2','13')
SELECT id FROM ranks WHERE name = 'Moderator'
SELECT id FROM ranks WHERE name IN ('A10','Moderator','P1')

API Support for Category Subscriptions

See these guides in the Developer Documentation Portal:

• Create a category subscription
• Delete a node subscription by target ID
• Retrieve nested subscriptions

FreeMarker

We’ve added new builder methods on the webuisupport FreeMarker context object to create or modify a URL.

• webuisupport.urls.getBuilder(String url, boolean fullyQualified)
• webuisupport.urls.getBuilder(String url)

The builders include convenience methods to define path elements, query parameters, and hash parameters.

Generate a fully-qualified URL

${webuisupport.urls.getBuilder("/some/url").build()}
## => http://currentdomain.com/some/url

Generate a relative URL with a hash

${webuisupport.urls.getBuilder("/some/url", false).hash("foo").build()}
## => http://currentdomain.com/some/url#foo

You Found It. We Fixed It.

• We have fixed the issue where members with the Upload Images permission could upload image to another user’s public folder.
• We have fixed the issue where the first-time visit to a top-level category did not respect the language setting for that category.
• Unexpected errors are no longer thrown on the LSI Value Analytics tab.
• Previously, Community conversations that included emojis appeared empty when viewed in Khoros Care (Response). This issue has been fixed, and now these conversations display properly.
• Running an API call that includes "ORDER BY metrics.views" now displays the entries in the correct order.
• We have fixed the discrepancy between the number of Kudos a member received that appears in metrics versus what’s displayed in the member’s profile.
• Clicking the Preview button for a case in the Case Portal no longer throws an unexpected error.
• Previously, the Bulk Data API did not always return all the activity details on a specific post. This issue has been fixed.
• We have fixed the issue where certain file types listed in the supported file types list were not able to be uploaded. Now, all valid files matching supported file types for a community will upload without error.
• When updating a TKB article using an API call, the update date of the article is now updated properly.
• We have fixed the issue where negative metrics were getting reported for certain activities.

We have fixed the display issue where editing the table properties in a table in a TKB article could not be saved because the Submit button displayed below the viewable area.