It's hard to believe that Summer is here already! We hope that you and your loved ones are staying healthy and well as we continue to navigate the road ahead. The Khoros Communities team is working hard on new features coming in future releases. Stay tuned for Early Access announcements.
In the meantime, we have improvements, bug fixes, and API updates to share with you.
Feature Enhancements
Rate Limiting on Abuse Reports
We've introduced flood limit controls on the Abuse Notifications feature (also referred to as the Report Inappropriate Content feature). Abuse reports are created when a customer clicks the Report Inappropriate Content link in a Community post and submits a report. Flood limit controls prevent flooding the inbox of moderators when users repeatedly submit abuse notifications.
Learn more about rate limiting on abuse reports.
Maximum number of Broadcast private message recipients increased
We have increased the default maximum number of recipients in a single Broadcast private message from 1,000 to 10,000.
NOTE: For communities in version 20.5 and below, Group Messaging is limited to 1,000 users per message by default. For communities in version 20.6 and later, this limit is set to 10,000 users per message by default.
As part of this, we have also enhanced the error handling experience around the maximum limit. From 20.6, an error message will be displayed if the number of recipients on a message exceeds the maximum configured for the Community.
Learn more about sending private messages to a group of community members.
This increase does not affect the maximum limit applied to Multi-user private messages. Multi-user private message limits are set in Community Admin > Features > Private Messages with the Maximum number of users who can be included in a multi-user private message setting.
Learn more about Broadcast and Multi-user private messages.
API Updates
We've added new capabilities to the Community API v2 Message, Node, and Group Hub APIs.
- Mark messages as read with a LiQL query
- Return whether a user is the owner of a membership node
- Sort users in a membership node by their join_date
- Get messages by group hub ID
- Join an open group hub
- Leave a group hub
Mark messages as read with a LiQL query
You can mark one or more messages as read in LiQL query to the Community API v2 messages collection.
Make a GET or POST request to the /search endpoint, passing a LiQL query to the messages collection along with the api.mark_read query parameter set to true. You must include the body field in the SELECT statement of your query, otherwise the api.mark_read query parameter will have no effect regardless of its value.
In the response, you will see that the user_context.read field set to true.
Example LiQL query
SELECT id, subject,body, user_context FROM messages WHERE author.login='NicoL' ORDER BY post_time DESC
Example URL
https://[COMMUNITY DOMAIN]/api/2.0/search?q=select id, subject,body, user_context from messages where author.login='NicoL' order by post_time desc&api.mark_read=true
See Mark a message as read for more details.
Return whether a user is the owner of a membership node
We've added the is_owner field on the Community API v2 users collection. This field is returned when the node.id constraint is included in the WHERE clause.
Example LiQL query
SELECT login, is_owner FROM users WHERE node.id = "grouphub:developerNetwork"
Sort users in a membership node by their join_date
We've added join_date as a sort on the Community API v2 users collection. The node.id constraint is required when sorting by join_date. You can use join_date as a standalone sort option or you can combine it with other sort fields. When combined with other sorts, join_date must be the first sort in the query.
Examples LiQL queries
SELECT id, login frFROMom users WHERE node.id = 'grouphub:developerNetwork ORDER BY join_date DESC
SELECT login, join_date FROM users WHERE node.id = 'grouphub:developerNetwork' ORDER BY join_date ASC, login DESC limit 10
Get messages by group hub ID
You can now use the grouphub.id constraint on the messages collection to filter messages by group hub ID. This constraint is supported in Community 19.6 and later.
Example LiQL query
SELECT id, board.id FROM messages WHERE grouphub.id = 'knittingGroupHub'
Join an open group hub
We updated the Community API v2
POST /nodes/<node.type>:<node.id>/membership_requests endpoint to support joining an open group hub. Previously, the POST method supported joining a closed or hidden group hub only. See Join an open membership node for details.
Leave a group hub
We added DELETE support to the Community API v2 /nodes/<node.type>:<node.id>/membership_requests endpoint. This endpoint enables a user to leave a membership node, such as a group hub, via the API. The endpoint mimics the Leave Group Hub option in the Options menu in the Community UI. See Leave a membership node for details.
You Found It. We Fixed it
- We have improved cross-site scripting (XSS) prevention to the Start Article and Edit Article TKB workflows.
- We fixed an issue where image uploads were failing on boards with numerical ID values.
- We fixed an issue where Community members without the Administrator role were unable to download their personal information via the Download Personal Information setting in the user profile. All community members can now download their personal information.
- We have fixed an issue with group-to-group hub migration where a migration would fail if a group being migrated to a group hub had the same ID as an existing category in Community. In addition, we now allow a group being migrated to use the same ID as a group hub.
- We have added accessibility support for the Insert Emoticons option in our rich text editor
- We have added rate limiting to abuse reports in response to this idea. See details in Rate Limiting on Abuse Reports.
