Blog Post

Release Notes & Updates
10 MIN READ

16.10 Release Notes

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

The 16.10 release includes new Lithium Responsive features, including the ability to create, edit, and delete TKB templates and add cover images to articles and posts. We’ve also made several updates to key LSI metrics, including an important update to how we calculate CHI. We’ve also made updates to our Salesforce and Microsoft Dynamics connectors.

New Features

Create and manage TKB templates from Community Admin (Responsive only)

We added the ability for Admins to create, edit, and manage TKB templates from Community Admin.

Note: You must be on TKB version 2.4 (or later) and Responsive version 1.10 (or later) to use these new TKB template management tools.

In the 16.5 release, we migrated the TKB templates from being rigid, hard-coded content areas to a more flexible, HTML-coded page. Read more about the TKB templates on Responsive in the 16.5 Release Notes.

In this release, we’ve added the ability for admins to edit and delete the out-of-the-box TKB templates (Freeform, Questions and Answers, and Solutions) as well as create new templates. Now, you can create and control the templates you want to use for different types of TKB articles.

Note: TKB template changes are global, not node-scoped. When you create, edit, or delete templates, those changes are applied to all TKBs on your community.

To create a new template:

  1. Go to Discussion Styles > TKB > Templates.

  2. Click Create Template.
  3. Enter the Title and Description of the template. (The Title is the template name that authors see when they start a new article and choose the template from the list.)

  4. In the Content area, enter any pre-populated text you want to appear in the body of the article when this template is used. For example, you might want to include specific header titles or boilerplate text.
    Tip: By default, all text entered into the template Content area can be edited by authors when they create articles. To make specific header text in the article non-editable, add the contenteditable=falseattribute to it. For example, if you wanted the first header in a “Concert Review” template to say “Reviews from the road”, you’d enter <h1 contenteditable=false>Reviews from the road</h1>  in the Content area. Then, when the author chooses that template, the text is pre-populated and can’t be changed. (However, they can still delete the entire line from the article.)
  5. Click Save.

The new template (in this example, “Concert Review”) appears in the TKB article list and the template chooser:

TKB article list:

TKB template chooser:

  

Clone a template

To save time when creating new templates, you can clone an existing template and use it as a starting point for a new one.

To clone an existing template:

  1. Go to Discussion Styles > TKB > Templates.
  2. Click Clone next to the template you want to use as your source template.

  3. Edit the template as needed, providing a new template Title.
  4. Click Save.

Edit a template

To edit an existing template:

  1. Go to Discussion Styles > TKB > Templates.
  2. Click Edit next to the template you want to change.
  3. Make your changes to the Title, Description, or Body.
  4. Click Save.

Note: Changes to an existing template do not change any existing articles that use that template. The changes apply only to new articles that use that template. 

Delete a template

To delete an existing template:

  1. Go to Discussion Styles > TKB > Templates.
  2. Click Delete next to the template you want to delete.

Note: Deleting a template that has already been used by existing articles has no impact on those articles, since the articles use simple HTML to display its contents.

Note: If you delete all the templates from the Admin template list, the TKB template chooser page does not display when authors create new TKB articles. The “template” provides a blank title and body area.

Cover images for masonry pages (Responsive only)

Community 16.10 enhances the Masonry Message List component to display a user-selected cover image in the Masonry tile for a topic (root) message.  

Note: Cover image selection in Masonry tiles requires feature versions Messages v2 and Responsive v2.

This feature is disabled by default. With Community Admin, you can enable this feature across the entire community, or for specific categories or boards. In addition, a user must have the Select cover image for messages permission granted to see and use the Cover Image component in the Community UI.

When this feature is enabled, a cover image overrides a teaser image or a body image in a Masonry tile. Cover images are not displayed for replies or comments.

Lithium recommends considering cover image selection an advanced permission given only to certain roles. We recommend coupling it with permission to bypass image moderation for communities that moderate images if your community uses a moderation flow for uploaded images. This avoids having a "pending image" placeholder display in the Masonry tile. Consider incorporating cover image selection into a rank-up incentive for your members, reserving it for superusers and other high-ranking members in your community.

To enable this feature:

  1. Go to Community Admin > Community Structure for the board or category where you want to enable cover image selection.
  2. Click Manage.
  3. Go to Features > Images.  
  4. Select Enable cover image selection for messages.
  5. Click Save.
  6. Go to Community Admin > Users > Permissions and grant the Select cover image for messages permission to the desired role.
  7. Click Save.

Selecting a cover image

Let's walk through selecting a cover image for a forum post. In this forum, we have a featured conversation including images from a community member’s trip to Mexico.

By default, the Masonry Message List component is using the first image uploaded in the message body. Suppose the community member who authored the message just ranked up to a new level and can now choose which image to display as the cover image.

She clicks on the Masonry tile and selects Edit Message from the menu option in the Forum Topic Page.

In the Edit Message page, she clicks on the Cover Photo component.

She can select one of the other images in the post or upload a new image.

She clicks Done to set the cover image. The new cover image displays in the Edit Message page. It can be edited at a later time, if needed.

The community member clicks Post to publish the change to the community. Back in the Forum Page, we see the new cover image in the Masonry tile.

 

Updates to the message editor

With the 16.10 release, we have updated to the 4.4.3 version of the TinyMCE message editor, which includes a number of fixed issues, listed on the TinyMCE site.

LSI metric calculation updates

Feature Availability: LSI updates will be available mid-November.

We have made several adjustments to improve how we calculate and report on specific metrics in LSI.

  • Mobile vs tablet: We backfilled our mobile, tablet, desktop breakdown data back to January 1, 2015. Previously, we only had device-breakdown data dating back to June 11, 2015.
  • Searches: We have improved the way we calculate searches (using search events) so you might notice a changes in these counts.
  • Members time online: We have fixed the bug where we weren’t showing the number of minutes members spent online.
  • Referrers: We have improved our URL parsing used to extract the hostname from a referrer URL. As a results of this work, you might see an increase in the number of referrers found.
  • Visits: We have changed the way we calculate session visits. Now, sessions terminate at midnight UTC. This approach results in much more consistent numbers and is in line with how Google Analytics calculates sessions. As a result of this change, you might see slightly more visits than before around midnight UTC.
  • RSS Views - Bots are no longer included in RSS Feed counts.

Updates to how LSI calculates CHI

Prior to this release, LSI computed CHI every 7 days at the week boundary Monday—Sunday. Now, LSI computes CHI daily. Daily CHI uses the same algorithm as before but now looks at a rolling 7-day window (uses the past 7 days of data from the day of computation).

Daily CHI fixes some of the boundary effects that arise as an artifact of the hard cut off time at the week's boundary. As a result, your raw health factors and quantile health score, and therefore the final CHI might change. 

 

5-star Rating Support for Contests with Lithium Responsive

Lithium Responsive now supports 5-star ratings for Contests. To configure 5-star ratings for contests, see Configuring the Ratings feature. To learn more about Community rating options, see About 5-star, Helpfulness, and Me Too ratings.

Salesforce and Microsoft Dynamics connector updates

We have made several improvements to the Salesforce and Microsoft Dynamics connectors/workflows, including:

Salesforce and Dynamics updates

  • Just-in-time user sync: When a case is escalated to the CRM from the community, we create an associated community user record in the CRM. Requires Lithium Connector v3 for Salesforce or Lithium Connector  v1.0.16.10 for Dynamics.
  • Knowledge article nomination:  Article nomination is now a separate menu option in both the Salesforce and Dynamics workflows. It now appears in the topic options menu:

Dynamics updates

  • Encryption key: We have added a required encryption key field in the Dynamics CRM-side configuration form to help improve the security of the Lithium solution.
  • New postback options: Upon closing a community-originated case in the Dynamics CRM, agent is given postback options.
  • Accepted Solutions now synced with Dynamics: Marking an accepted solution on a thread that has been escalated to Dynamics now reports the event to the Dynamics CRM and is reflected in the CRM case.

New Version of the Lithium SDK

We've released a new version of the Lithium SDK. Follow the update instructions in the Lithium SDK documentation.

API Changes

Community API v2

Deprecated field on Users collection

We have deprecated the kudos_received.count(*) field on the Users collection. Any LiQL queries using kudos_received.count(*) should be updated to use kudos_received.sum(weight).  kudos_received.sum(weight) provides more accurate information. 

Supported uses of kudos_received.sum(weight) in queries on the Users collection include:

 

SELECT kudos_received.sum(weight) FROM users
SELECT * FROM users ORDER BY kudos_received.sum(weight) DESC
SELECT id FROM users WHERE kudos_received.sum(weight) > 0

New cover_image field on the Messages collection

The cover_image field on Messages works with the new Cover Image Selection feature introduced with this release.

You can use HTTP GET, POST, and PUT to create messages with a cover image, update the cover image for a message, and return cover image details for a specific message.

The calls in this section require Messages v2+, Responsive Peak/Base v2+, cover image selection enabled in Community Admin > Features > Images, and Select cover image for messages permission granted for the user making the call. 

Examples

Create a message including a cover image

 

POST /community/2.0/mytenantid/messages HTTP/1.1
Host: api.lithium.com
Content-Type: application/json
Cache-Control: no-cache
client-id: czY8mbW76Ac/Wz6+bAMhCm+sW5WSyhAO2odh28TB1/c=

 

{
   "data": {
       "type": "message",
       "subject": "Cover image fro blogs - testing via API",
       "body": "This message should have 1351iF166279A9A1D65BF as a cover image",
       "board": {
           "id": "fall-treats"
       },
       "cover_image": {
           "id":"1351iF166279A9A1D65BF"
       }
   }
}

 

Edit the cover image on a message

 

PUT /community/2.0/mytenantid/messages/425 HTTP/1.1
Host: api.lithium.com
Content-Type: application/json
Cache-Control: no-cache

 

{

   "data": {

       "type": "message",

       "subject": "Cover image or blogs - testing via API - edited",

       "body": "This message should have 1336i3B4A7945D1A4A93B as a cover image after edit",

       "board": {

           "id": "fall-treats"

       },

       "cover_image": {

           "id":"1336i3B4A7945D1A4A93B"

       }

   }

}

 

Retrieve cover image details with LiQL

 

SELECT cover_image FROM messages where id =  '371'

SELECT * FROM images WHERE messages.id = '371'

HTTP GET http://lithcx.qa.lithium.com/api/2.0/messages/7790?fields=cover_image

Note: The cover_image field must be called explicitly in the SELECT statement of a LiQL query. It is not returned with SELECT * FROM messages, for example. If no cover image exists for a message, the field is not returned.

New association_type value supported on the Images collection

The association_type constraint on the Images collection now supports ‘cover’ as a value in addition to ‘teaser’, ‘body’, and ‘quote’. You must also constrain by messages.id.

 

SELECT * FROM images WHERE messages.id='371' AND association_type='cover'

Lithium SDK requires update

When upgrading to 16.10, you must also upgrade the Lithium SDK to version 1.3, if you use the SDK. To do this, you must update your SDK project and plugin.

Run this command from your terminal from any directory:

npm update -g lithium-sdk

Run this command from your SDK plugin root:

li update-project

You Found It. We Fixed It.

  • We have fixed the issue where a thread with only a root message (no replies) was not displaying in Responsive forums (version 3.5) when the sorting order within topics was set to “Newest first”. Now, these messages display normally.
  • Previously, when trying to access a URL that does not have a trailing slash, the HTTPS redirect didn’t work properly. This issue has been fixed and the redirect works as intended.
  • The issue where the search scope always defaulted to “message” when searching from the Community Page on Responsive has been fixed. Now, the search scope selection is retained and used.
  • We have fixed the issue where LIA displayed two locations for the robots.txt file.
  • Previously, the Sitemap index files incorrectly included the <changefreq> tag. Now, this tag no longer appears in the index file, per Google’s sitemap spec.
  • We have fixed the display issue where any word with more than 10 characters was not being highlighted properly on the search results page.
  • Previously, when users changed their passwords, not all of the auto-login cookies were being invalidated. This issue has been fixed, and now all auto-login cookies are invalidated.
Updated 7 months ago
Version 19.0

7 Comments

  • Not really - depends on the community really. Does it always look like this?

    Add to that the definitions of casual users and superusers are quite vague,so it's difficult to double check.

     

    What you can do is compare the number of members who signed in in the last 60 days with the number of members who posted. That *should* give you the 70/30 split as outlined above. 

     

  • So far this diagram has always displayed that 9-10% are superusers and rest are others. Now this is weird, like we don´t have superusers at all...

  • Hi there, 

    I was using the LSI Search (beta) report to get a sense of which search terms were being used and, of those, which yielded results and which did not.  

    With the release of 16.10, when I look at this report, it's like the search terms have switched places. By this I mean that the terms that are used in search daily are now showing in the "w/out results".

     

    So now, the Search (Beta) report reflects that over 90% of the search terms used didn't yield results.  
    I submitted a support ticket, but I understand that this report is in beta status.  I have access to view the search reports (message and user) on the Metrics tab in admin, but that doesn't tell me which terms were used and didn't yield results (I can see which search terms were used and the number of terms used that didn't yield results, but not the terms used that didn't yield results).

    Any future prospects of moving the LSI search (beta) report out of beta status? :)  

    Also, any suggestions on how I can get a better sense of terms used that didn't yield search results and what those terms were?

     

    Thank you. 

  • Hi, there is an issue with liql call

     

    USECASE 1 : a cover image has been uploaded for a message : 

    call

    SELECT cover_image FROM messages WHERE id = '51'

     

    answer

    {
    "status" : "success",
    "message" : "",
    "http_code" : 200,
    "data" : {
    "type" : "messages",
    "list_item_type" : "message",
    "size" : 1,
    "items" : [ {
    "type" : "message",
    "cover_image" : {
    "type" : "image",
    "id" : "55i62BEDD185DA474C2",
    .....}


    }

     

    USECASE 2 : a cover image has NOT been uploaded for a message : 

    call

    SELECT cover_image FROM messages WHERE id = '59'

     

    answer

    {
    "status" : "success",
    "message" : "",
    "http_code" : 200,
    "data" : {
    "type" : "messages",
    "list_item_type" : "message",
    "size" : 1,
    "items" : [ {
    "type" : "message",

    }

     

    The point is about the size data. Everywhere else, whene a liql query meets no result, size equals 0 in the answer. So, it's easy to have a  "<if query.data.size gt 0> ...<else>...</if>" to handle properly the case. 

    Here, i have to check if my query.data.items[0].cover_image.xx exists but i enconter an error before, because  data.items[0].cover_image doesn't exists.

     

    Can you please fix it or give a workaround ? 

     

    Thank you very much

    In a custom component, i 

  • PaoloT's avatar
    PaoloT
    Lithium Alumni (Retired)
    9 years ago

    Hi jferrandis - I've noticed that behavior myself and I have raised an internal ticket for review. Thanks for raising this. 

  • AndrewD's avatar
    AndrewD
    Lithium Alumni (Retired)
    9 years ago

    jferrandis
    The size field is what we would expect. LIQL queries work a lot like SQL queries.

    The query SELECT cover_image FROM messages WHERE id = '59' essentially says give me all messages with the id 59 but only show me their cover image field. So we return the messages which meet the constraint (id = '59') but only include the fields requested (cover_image). In this case there is nothing assigned to cover_images.

    Where looking into whether excluding an empty field is the best course of action or if we should return some sort of null or empty value. 

    A possible work around exists but at the moment it only works if you want a cover image for a single message. I would return images constrained by their association type and message id. It would look like:

    SELECT * FROM images WHERE messages.id = '59' AND association_type="cover"

    This returns all images used as a cover image in the message with id 59. If none exists the size will be 0 since no images meet that constraints.