17.2 Release Notes

In the 17.2 Release, we have improved the layout and overall usability of the ActiveCast tab in Community Admin. We've also added the ability for you to self-register your own Community API web applications in Community Admin. Finally, we've made several API changes and provided some updates in the Developer Documentation Portal. 

New features 

• Self-registration of API web applications (OAuth2)
• New ActiveCast layout
• API changes
• Developer Documentation Portal updates

Self-registration of API web applications (OAuth2) 

You can now register Community API applications directly in Community Admin, making it easier to build secure web applications based on Lithium.   

Registering an API application provides you with the OAuth2 client credentials required to use the Lithium API proxy.  

See API Keys for instructions under the APIs menu in the Developer Documentation Portal. 

New ActiveCast Layout 

We've changed the layout of the ActiveCast tab in Community Admin from a subtab interface to a component chooser similar to the one used in the Studio Page tab.  

 

In a future release, we will add help text and example images in a hover card for each ActiveCast widget in the chooser, just as we do for Studio components. 

API Changes 

We've added new functions to Community API v1 and v2. 

Community API v2 

Messages resource: Filter messages by teaser text 

You can now constrain queries to the messages collection by teaser text using MATCHES in the WHERE clause.  

Example:  SELECT id, subject, author.login  FROM messages WHERE teaser MATCHES 'sometext' 

Messages resource: Exclude an author from message queries - examples will change 

You can now use != in the WHERE clause in queries to the messages collection to exclude an author by login or ID. 

Examples:  

SELECT subject, id, view_href, author.login FROM messages WHERE author.login != 'SuzieH' 

SELECT subject, id, view_href, author.login FROM messages WHERE author.id != '32' 

 

Community API v1 

Silencing email notifications for moved messages 

With the move/board/id/<board_id> call on the Message resource, you can now  silence email notifications for message moves. To disable notifications, pass the move_message.ignore_notification parameter with the value set to true.  

Support for this parameter has been backported to 17.1 and 16.12. 

http://community_url/restapi/vc/messages/id/56/move/board/id/forum2?move_message.ignore_notification=true&move_message.include_replies=true 

New calls to set, reset, and get metadata 

Community API v1 now supports the following calls on UploadedImage, Product, and ProductCategory: 

• metadata/key/[key] 
• metadata/key/[key]/set 
• metadata/key/[key]/reset 

Developer Documentation Portal Updates 

We’ve added overview information about the Community Android SDK to the Dev Doc Portal under the SDKs and Tools menu (formerly called Dev Tools). We’ve also renamed the Lithium SDK to the Community Plugin SDK (or Plugin SDK for short). 

You Found It. We Fixed It. 

• We have fixed the issue where content in nodes configured to use a language with a hyphen in its plug-in entry (for example, pt-br, es-mx, or en-gb) were not being indexed by Elasticsearch. Now, content in these nodes are indexed properly. 
• We have fixed the issue where you could not move messages if your community language was set to a language which contained a hyphen in its name (for example, pt-br, es-mx, or en-gb). Now, you can move messages without receiving an error. 
• We have fixed the issue where Private Message responses in topics that had been escalated to Salesforce were not getting attached to their corresponding Salesforce cases. 
• Many communities are configured so that users must verify their email address before they can post to the community. When users submit a post before their account is verified, the posts are placed in a "hold" status. Normally, when the user later verifies their email address, the posts get released from the hold and submitted. However, there were a few scenarios where this wasn't happening, and the posts remained in the hold state. These issues have been resolved, and the posts are now handled properly after the user verifies their email address. 
• Previously, if a user received a notification in their feed about some event that happened in a node that the user no longer has the proper permissions to view, the notification feed would throw an unexpected error. Scenarios where this could happen include when a user is subscribed to a board and a post in that board is moved to a different board that the user can't access, or when a user subscribes to a thread and the thread is moved to a different node, then they lose access to the original board because the customer changed their permissions. Now, in these types of scenarios, the feed does not produce an error, and instead the user receives a better message that indicates that the board or thread is unknown/not available to them, based on their permissions. 
• We have fixed the display issue where the permissions list headers in Community Admin > Users > Permissions were not aligned with the appropriate columns.  
  Before:  
   
  After:  
   
• We have fixed the issue where community users who had custom data set on their profile that wasn't defined in the community's input.cfg file were not being indexed properly, resulting in errors being thrown during startup. These indexing issues have been resolved.  
• Previously, when you ran a user search and filtered for a specific rank, you'd get results with users who had a different rank. This issue has been fixed, and now the rank user search returns the correct list of users.