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 Admin (Responsive only)
- Cover images for masonry pages (Responsive only)
- Updates to the message editor
- LSI metric calculation updates (available mid-November)
- 5-star Rating Support for Contests with Lithium Responsive
- Salesforce and Microsoft Dynamics connector updates
- New version of the Lithium SDK
- API updates
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:
- Go to Discussion Styles > TKB > Templates.
- Click Create Template.
- 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.)
- 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="false"attribute 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.) - 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:
- Go to Discussion Styles > TKB > Templates.
- Click Clone next to the template you want to use as your source template.
- Edit the template as needed, providing a new template Title.
- Click Save.
Edit a template
To edit an existing template:
- Go to Discussion Styles > TKB > Templates.
- Click Edit next to the template you want to change.
- Make your changes to the Title, Description, or Body.
- 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:
- Go to Discussion Styles > TKB > Templates.
- 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:
- Go to Community Admin > Community Structure for the board or category where you want to enable cover image selection.
- Click Manage.
- Go to Features > Images.
- Select Enable cover image selection for messages.
- Click Save.
- Go to Community Admin > Users > Permissions and grant the Select cover image for messages permission to the desired role.
- 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.