Blog Post

Release Notes
14 MIN READ

Khoros Communities 19.9 Release Notes

JohnD's avatar
JohnD
Khoros Alumni (Retired)
6 years ago

New Features

Improved Private Messages (EA)

We are excited to announce Early Access release of Private Messenger v3. Private Messenger v3 has been completely overhauled to increase your efficiency and productivity with new features, a more modern UI, and improved private message workflows.

In this initial release of Private Messenger v3, private messages are presented in a “threaded” view and a streamlined inbox experience:

With Private Messenger v3, your 1-to-1 private message conversations display as threaded:

Additionally, you can create broadcast (1-to-many) private messages, each of which will create their own 1-to-1 threaded conversation in your Inbox when each recipient replies:

Between now and the GA Release of Private Messenger v3, we plan to provide additional features, including:

  • Multi-user Private Messages (group private messaging)
  • Support for attachments (including drag-and-drop)
  • Full API support

To request access to the Private Messenger v3 EA Release, open a Support ticket.

New inline link editing options from message editor 

We’ve added several inline link editing options for when you are using the messaging editor. Now, when you click on a link or use the arrow keys to move the cursor over a link in your post, the inline link pop-up menu displays:

From the inline link pop-up menu, you can click:

  • Edit Link: Opens the link editing window where you can change the existing link.
  • Unlink: Removes the link associated with this text.
  • Bare URL: Displays the actual URL of the link instead of the website title. (If the Bare URL is active, this button is disabled and greyed out.)
  • Auto Title: Displays the title of the linked webpage for the link text. (If the Auto Title is active, this button is disabled and greyed out.)
  • Open Link: Opens the linked URL in a new browser tab.

Note: Inline link editing requires Editor v2.2. Learn more about feature versions.

Discussion Style icons for content mentions

Mentions v2 introduced the ability to mention specific pieces of content, similar to the way you can mention other community members. We have enhanced content mentions to add an icon before the content mention that indicates the type of content being mentioned (forum, blog, TKB, etc.). With this additional visual indicator, users know what type of content they are choosing to view when they click these mention links.

For example, a content for a TKB article might look like:

The icons used for each content mention type is as follows:

Note: You must be on Mentions v2.1 to use this feature. Learn about feature versions.

New permission to access member bulk export

Up to now, Khoros Communities included two user permissions for regular or admin access to Community Analytics (formerly called LSI). Both of these permissions provided full access to the metrics in the Members tab.

With the recent addition of the Members bulk download feature introduced in 19.8, we have added a new “advanced analytics” permission for Community Analytics called Export Member metrics in bulk from Community Analytics. Since the member bulk download report includes PII data for community members, Community managers might not want all Community Analytics users to have access to this sensitive data. To restrict access to this information, we recommend granting this new permission to specific, trusted members. 

Only community members with the Export Member metrics in bulk from Community Analytics permission can download the bulk member report, from the Members tab:

To grant this elevated Community Analytics permission:

  1. Sign in to the Community as an Admin.
  2. Go you Community Admin > Users > Permissions.
  3. Edit the role or member to whom you want to grant this permission.
  4. Scroll down to the Community Analytics permissions section and Grant the Export Member metrics in bulk from Community Analytics permission.
     
  5. Click Save.

Additionally, we have added a new, default Community role (AdvancedAnalyticsUser) to that grants this permission:

Members granted this role are also able to download the member export.

Note: The normal Analytics role no longer grants the ability to download this report. The Admin role includes this role/permission by default.

Drop-down menus for Rank and Role filters in Community Analytics 

Community Analytics enables you to apply various filters to reports to view the exact information you want. Up to now, when filtering for specific ranks or roles, you needed to manually enter the rank/role name when building the filter.

Now, both the Rank and Role filter options provide a drop-down menu so you can view all the available options and choose the rank/role you want from a list.

Rank Filter chooser:

Role Filter chooser: 

Learn more about applying filters to Community Analytics reports.

Khoros CRM Connector Salesforce Files Support (EA)

The Khoros Salesforce Connector 4.2 now takes advantage of the Salesforce Files feature. When attaching files to Khoros Case Portal records (creation, updates, or comments) or via the community post-escalation workflow, these file attachments are stored as Salesforce Files objects, rather than as attachment objects.

Note: To request the Salesforce Files support be enabled for your community, open a Support ticket. No further action is required by you to implement or use this feature. All workflows remain the same on your community. 

Note: Files previously uploaded as attachments will not be migrated to the Salesforce Files section.

New node components

In Community release 19.9, we added several, new node-level components:

  • Child Node Summary
  • Node Information
  • Node Avatar
  • Node Message List (Preview)

We added these components to a new section of the Components list in Studio > Page called Nodes. We also moved the following existing node-level components previously located under Page Elements into the new Nodes section.

  • Node Detailed Description
  • Node Details
  • Node Icon
  • Node Title and Description

Child Node Summary

The Child Node Summary component displays the direct child boards within a Community, Category, or Group Hub node along with the count of topics in each board. The component does not include container nodes (subcategories/group hubs) in the summary list. The component displays the Short Title of each board as defined in Community Admin, or the Title of the board if a Short Title is not set.

Node Avatar 

Component ID: nodes.widget.avatar

Note: To enable Node Avatars open a Support ticket.

The Node Avatar displays the avatar set for the node in Community Admin > Community Structure when creating or editing a node. 

Child nodes inherit the node avatar from their parent node, unless a node avatar is set at the child node-level. Use this component on the Category Page, Group Hub Page, and any board-level page (e.g., Forum Page, Blog Page) except the Group Page.

If you are working with a Group Hub, you can also set the node avatar in the Community UI Group Hub Create and Group Hub Edit forms.

Community Admin

Community UI

This is an example of the Node Avatar component. It is often used as a subcomponent within another component. (See Node Information as an example.)  

Node Information

Component ID: nodes.widget.node-info

The Node Information component displays the node avatar, title, description. For group hub nodes, the component also displays the membership count and date created (in the date format defined for the community in Community Admin).

Use this component on the Category Page, Group Hub Page, or any board-level page (e.g., Forum Page, Blog Page) except for the Group Page.

Node Message List (Preview)

Component ID: nodes.widget.activity

The Node Message List (Preview) component displays a list of topics within the node and its subnodes. Each topic listing includes a preview containing the subject, author details, a text snippet, up to 2 images, and an indicator of any unread items since last visit.

This component works best on the Category Page, Group Hub page, or Community Page.

Reminder: Sunset of API Proxy for Community API

We will be sunsetting the API Proxy when used to authenticate calls to the Community API over HTTP with OAuth 2.0 authorization grant flow with the Community 19.10 release (October 2019). This change will primarily affect customers who have used OAuth 2.0 to authenticate calls to the Community API. We will also be deprecating the GET /validate/oauth endpoint used to validate the OAuth access token and replacing it with the new GET /validateToken endpoint.

Instead of going through the API Proxy service, all Community API calls will be routed directly to Community servers. Because we will no longer be going through the API Proxy, calls authenticated with OAuth 2.0 will no longer use the API Proxy URL structure.

  • Customers who do not currently use OAuth 2.0 for API authentication but who choose to use it with 19.4 release or later must use the updated API URL structure described in our latest OAuth 2.0 authorization grant flow guide. (We have also updated our API v1 and API v2 guides that describe the Community API URL format and our guide for obtaining API keys.)

  • Customers who have made Community REST API calls authenticated with OAuth since 19 April 2019 should begin migrating calls that use the API Proxy URL to use the new URL structure. There is a grace period of six months where the API Proxy URL will continue to work without interruption. Khoros Support will reach out to customers who fall into this category before Stage sites are upgraded.

See full details and an FAQ in this blog post.

New API URL for Community API v1

The Community API v1 call URL for all calls to the Community API now looks like this:

https:/[COMMUNITY DOMAIN]/restapi/vc/[OBJECT PATH][METHOD PATH]

where

  • COMMUNITY DOMAIN  is the host URL of the community
  • OBJECT PATH is the path to the object you want to work with
  • METHOD PATH is the method to call

Example https://community.khoros.com/restapi/vc/boards/id/productIdeas/threads/latest

New API URL for Community API v2

The Community API v2 call URL for all calls to the Community API now looks like this:

https://[COMMUNITY DOMAIN]/api/[VERSION]/[RESOURCE]

Where:

  • COMMUNITY DOMAIN is the host URL of the community
  • VERSION is the version of the Community API: Always 2.0
  • RESOURCE is the API v2 resource to work with

Example

This is the API URL structure for an API call to the Khoros Community: https://community.khoros.com/api/2.0/[RESOURCE]

Updates to Khoros email system requiring changes to your SPF records

We are making some improvements to our mail system to make it more resilient and easier to manage. Additionally, we are taking this opportunity to change our default outgoing email address to align with our company name change. As part of this, you might need to make some changes on your side.

To determine whether you need to make changes, go to Community Admin > System > Mailer and review the Mailer Email Address field. 

  • If you are using mailer@lithium.com: No action needed on your part, but we will be changing the domain communities send email from to mailer@us.khoros-mail.com or mailer@eu.khoros-mail.com (depending on hosting location) by the end of November.
  • If you are using a custom mailer: For us to be able to continue to send authorized email on your behalf, you must change the SPF record of the domain configured in your community. For community email to function properly, you must make these changes by November 30, 2019. See SPF Instructions for details on how to set up your SPF record properly.

Alternatively, you can append this string to the end of your community URL:

/t5/bizapps/bizappspage/tab/community%3Aadmin%3Asystem%3Amail-sender%3Asettings?setting=mail.sender_email_address

Note: We are still reviewing to discover if extra work is needed for DKIM, but currently we do not believe any further changes are needed outside of updating your SPF record.

API Updates 

This release, we’re announcing changes to the ORDER BY block in a LiQL query and we’ve released a more efficient option for pagination with Community API v2.

  • Default sort orders for LiQL queries coming in 19.10
  • Cursors support for pagination with Community API v2

Default sort orders for LiQL queries coming in 19.10

To improve performance on LiQL queries that return large datasets (over 10,000 records), we will begin applying default sort orders in the ORDER BY block of queries to the following collections when no sort order is defined:

Sort order defaults

Collection

Default Sort Order

The default sort order for queries to the messages collection that returns both topic messages and/or replies 

ORDER BY post_time DESC, id DESC

Default sort order for a query to the users collection

ORDER BY registration_data.registration_time DESC, id DESC

Default sort order for queries to:

nodes

boards

categories

group_hubs

ORDER BY depth ASC, position ASC

How will this affect me?

Existing queries to the collections mentioned above will not be affected if the queries already use the ORDER BY block. 

Existing queries to the collections above that do not include ORDER BY will likely see a change in the order of the result set. 

Let’s look at this  example LiQL query:

SELECT id, post_time, subject FROM messages WHERE depth=0 LIMIT 3

Without a default sort order, the result set will look something like this:

 

 

 

 

 

 

{
  "status" : "success",
  "message" : "",
  "http_code" : 200,
  "data" : {
    "type" : "messages",
    "list_item_type" : "message",
    "size" : 3,
    "items" : [ {
      "type" : "message",
      "id" : "1124",
      "subject" : "test script",
      "post_time" : "2019-08-28T14:59:21.617-07:00"
    }, {
      "type" : "message",
      "id" : "1122",
      "subject" : "scriptTestEditorV1",
      "post_time" : "2019-08-28T14:42:29.426-07:00"
    }, {
      "type" : "message",
      "id" : "1123",
      "subject" : "scriptTestEditorV2",
      "post_time" : "2019-08-28T14:50:40.857-07:00"
    } ]
  },
  "metadata" : { }
}

 

 

 

 

 

 

With the default sort order for queries to the messages collection constrained by depth=0 (ORDER BY post_time DESC, id DESC), the result set will be ordered like this:

 

 

 

 

 

 

{
 "status" : "success",
  "message" : "",
  "http_code" : 200,
  "data" : {
    "type" : "messages",
    "list_item_type" : "message",
    "size" : 3,
    "items" : [ {
      "type" : "message",
      "id" : "1129",
      "subject" : "Love the trail running shoes",
      "post_time" : "2019-09-03T12:13:07.786-07:00"
    }, {
      "type" : "message",
      "id" : "1145",
      "subject" : "Get started with Group Hubs Early Access",
      "post_time" : "2019-09-06T10:08:50.684-07:00"
    }, {
      "type" : "message",
      "id" : "1144",
      "subject" : "Which blog will this post to?",
      "post_time" : "2019-09-05T08:53:32.506-07:00"
    } ],
    "next_cursor" : "AAAADFrdm-DNsB_cx5NKGC5SBXA1JZaP2znRivVtK7-mnd89kvitmuEQZbEyrTh76WcqekJRx9osNvISp-_QmhIHepgWrA"
  },
  "metadata" : { }
}

 

 

 

 

 

 

What actions should I take?

Noting at the moment. Once your stage environment is updated to 19.10, however, review components and other customizations in your stage environment to verify whether the order of messages, users, boards, categories, and group hubs are listed in the order you want. 

Can I get the default sort order enabled before 19.10?

You can. You can open a Support ticket once your community is upgraded to 19.9 and request that “default sort order” be enabled for your community. Early enable is suggested only for customers who have experienced performance problems related to using large OFFSET values in LiQL queries. 

Pro tip: Check out our new cursor support for pagination as a better-performing alternative to LIMIT/OFFSET in Community API v2 customizations. 

Cursors support for pagination with Community API v2

Update: We have uncovered a bug that causes issues with pagination when using cursors with the nodes, categories, boards, and grouphubs collections. Using cursors for pagination with these collectsion is not supported at this time. We expect to release a fix for this issue with the 19.12 release.

We have added cursor support for pagination to Community API v2 LiQL queries.

Using cursors is a more efficient alternative to OFFSET, especially when paging through large result sets (e.g., over 10,000 records). We recommend using cursors for pagination in all future customizations using Community API v2. LIMIT/OFFSET will continue to be supported, and it is still an acceptable paging method in testing and for small result sets.

Once your community is upgraded to 19.9, all LiQL queries to Community API v2 will include a next_cursor field in the response.

Cursors in general, especially when combined with a sort order defined in the ORDER BY clause, provide better performance and decrease the chance of duplicates in the results of LiQL queries.

In your LiQL query, use LIMIT to define the number of records to return in the result set. 

Example

SELECT id, login, registration_data.registration_time FROM users WHERE registration_data.registration_time < 2019-03-29T22:18:20.259-07:00 ORDER BY registration_data.registration_time DESC, id DESC LIMIT 20

The response will return up to the LIMIT of records along with a cursor.

{
  "status" : "success",
  "message" : "",
  "http_code" : 200,
  "data" : {
    "type" : "users",
    "list_item_type" : "user",
    "size" : 20,
    ...
    }   
  }],  
  "next_cursor"
"AAAADLKxMmu6G2Ufv1ZgKrpHkPfTbiLOIWI3T76kPr6QZ4cb4a2wIu7MUWCNM8EjIfaFwAS73p3P/Z9pRREikj/R7oNA+giYVw"
},

To get the next set of results, pass the cursor returned in the next_cursor field as the value of the CURSOR key in your next LiQL query.

SELECT id, login, registration_data.registration_time FROM users WHERE registration_data.registration_time < 2019-03-29T22:18:20.259-07:00 ORDER BY registration_data.registration_time DESC, id DESC LIMIT 20 CURSOR 'AAAADLKxMmu6G2Ufv1ZgKrpHkPfTbiLOIWI3T76kPr6QZ4cb4a2wIu7MUWCNM8EjIfaFwAS73p3P/Z9pRREikj/R7oNA+giYVw'

You Found It. We Fixed It.

  • We have fixed the issue where double-byte and special characters were not displaying properly in Community Analytics (formerly called LSI) reports.
  • We have fixed the issue where historical user post counts were getting mistakenly capped at 2000.
  • Previously, there was an intermittent issue when working in multiple Studio tabs on Google Chrome, where changes in one quilt would be silently applied to the quilt open in the other Studio tab. We have fixed this issue. However, we still recommend avoiding having multiple Studio tabs open in the same session or use a different browser to avoid any future, possible edge cases where quilt contents could get overwritten accidentally.
  • We have fixed the issue where time-out errors were being thrown in Community Analytics when trying to export very large reports that took much longer to process.
  • Previously, the rank.id object in Community API v2 returned rank IDs with the same or similar names, despite the fact that they had different IDs in the system. This issue has been fixed.
  • Previously, when opening the navigation (“hamburger”) menu on a Category or Board page nested in a Category on a community using top-level categories, the menu was mistakenly scoped to the Community node, showed the Back button to get to the Community node, and showed child boards at the Community level. We have fixed this issue, and now when on a Category or Board page nested in a Category, the navigation menu is properly scoped to the top-level category, does not show a Back button to get to the Community node, and does not show child boards at the Community level. 
  • We have fixed the issue where the “View solution in original post” was not getting displayed on threads marked as Accepted Solutions when this feature was enabled.
  • We have fixed the issue where on some communities using ElasticSearch, boards names were duplicated on the “All Boards” page. Now, board names appear only once in the list.
  • Previously, when using the Insert/Edit Code option in Editor v2, certain combinations of characters resulted in the code sample being blank. This display issue had been fixed.
  • When using Editor v2 and having the Features > Images > Strip exif orientation metadata setting enabled, users on iPads or iPhones could not upload images from their device and instead received an HTML permission error. This issue has been fixed and now users with the appropriate permissions can upload images without error.
  • Previously, the /users/id/<user id>/posts and /users/id/<user id>/posts/count REST API v1 calls were returning inconsistent results. This inconsistency has been fixed. For example, now if the /users/id/10124/posts/count API call returns 3, calling the /users/id/10124/posts would return 3 posts.
Updated 7 months ago
Version 14.0

61 Comments