Recent Content
json query syntax matches AND OR
Hello, I cannot find the full json query syntax documentation here. Thats wha I'm asking in this post: How does a json based query look like for AND matches in body text. I want to query all posts containing term1 AND term2 in their body. My query currently is this. How do I add the term2? [ { "messages":{ "fields":[ "id", "subject", "search_snippet", "body", "cover_image.view_href", "teaser", "view_href", "author", "conversation.last_post_time", "replies.count(*)", "kudos.sum(weight)", "metrics.views", "labels" ], "constraints":[ { "category.id":"DE", "conversation.style":"tkb", "body":{ "matches":"term1" }, "depth":0 } ], "sorts": [ "post_time desc" ], "limit":10, "subQueries":{ "labels":{ "fields":[ "text", "id" ] } } } } ]Khoros Communities: Aurora 25.03 Release Notes
7 MIN READ The Khoros Communities: Aurora v25.03 Release introduces performance improvements, several new permissions, the ability to download your case list, moderation enhancements, post activity limit updates, improvements to the developer experience, and many bug fixes to improve the member experience.Aurora: View the history of published content
Over time, content posted to the community can change as different people edit the content. These changes can be subtle or complete rewrites of the original content. Sometimes, changes get made that are not correct or need to be reverted to an earlier iteration of the content. Aurora gives you the ability to track the changes in every version of a blog post or knowledge base article from its draft state up through its current published state. Each time you publish a KB article or blog post, the major version number is incremented (v1.0, v2.0, and so on). For example, in v1.0, 1 is the major version number and 0 is the minor version number. The minor version number is always zero for a published article. Each time you edit and save a published article, the major version number remains the same as the current version number and the minor version number is incremented (v2.1, 2.2, and so on). For every version, you can see who made the change and what was changed. Let's look at an example of the version history for a knowledge base article. To view the history of revisions: Go to the KB article page. Click History. The revision history of the article displays in a popup window: The published version gets an incremental version number (v1.0, V2.0, v3.0, …) From the Version History view, you can: view the revision notes that were added while editing the article. Compare the versions of the article. Edit and restore any older version of the article. Permissions View history of blog posts and knowledge base articles Set the permission View edit history under Settings > Roles and Permissions > Content to allow members to view and compare different versions of blog posts and knowledge base articles.Aurora: Activity limits
Activity Limits settings limit rapid actions like publishing, commenting, or private messaging within short intervals in your community. For example, if a member attempts to publish or send private messages or post images too frequently, they will be temporarily restricted, ensuring the community remains focused on meaningful engagement rather than automated or disruptive behavior. You can find this setting under Settings > Moderation > Activity Limits. Below is a screenshot of Activity Limits feature options: There are three sections under Activity Limits: Default Limits: These limits are set at the community level and apply to all members. Select Edit for Default Limits to enter activity limit values. A window to enter the number of posts at various intervals of time opens. In the Duplication limit in 1 hour field if you enter: 0, then there is no limit on duplicate posts. Members can post any number of identical posts. 1, then no duplicate posts are not allowed. 2 or higher, then members can publish up to the specified number of identical posts. Role-Based Overrides: You can specify specific roles from your community and set different activity limits. For members with these roles, the limits defined in this section override the default limits. Select Edit for Role-Based Overrides to enter activity limit values. In the Apply only to following roles field, add the roles that should have different limits from the default. Role Exclusion: You can specify community roles whose members should be exempt from activity limits. These are trusted members, or most often, Admins and Moderators. Also, when added, all members with these roles are automatically granted the Bypass activity limits permission. Select Edit for Role Exclusion to add roles. Note: The Bypass flood control permission that was introduced in Aurora version 24.12 is now renamed to Bypass activity limits.Aurora: Enable content moderation and set content moderation defaults
Community moderators review and process large volumes of member-generated content. Moderation is an important part of keeping a community a safe and engaging space for your members to participate. Depending on how you configure the moderation settings, content can also be auto-approved and skip the moderation process. The moderation process depends on the defaults you set for various boards. Admins can set these moderation defaults for forum discussions and replies, blog comments, ideas and their comments, event and event comments, media, and knowledge base comments at the community, category, and board levels. Auto-approved: The content is auto-approved and made public without going through moderation review unless flagged. Recommended for trusted areas that are self-regulated by a small group of members. Selective: The content is made public to the community without going through moderation. However, moderators can selectively review this content later, and based on the review, the content stays or is removed from the community. Required: The content must go through moderation for review, and based on the moderator's evaluation, the content is either published or removed from the community. By default, Selective moderation is set for all boards. Understanding the different moderation types Before configuring the content moderation defaults, you must understand the benefits and risks of each option: Auto-approved: Set Auto-approved for places that are designed for open discussions without any need for regulating the content posted by members. Use this option in places that are self-regulated by a small group of members who are accountable for their actions. However, we still recommend you implement the moderation process within the community to avoid spreading inappropriate information. Selective: Similar to Auto-approved, the Selective moderation process also encourages open communication among members in that they can publish content immediately without prior review. Moderators can still review the published content to ensure the posted content is appropriate and adheres to the community’s principles. Use this option in places where members expect fast-paced and live interaction without having to wait long for the moderation process to complete. However, when moderation is delayed, there is the potential risk of inappropriate content (abuse or spam) being posted that impacts readers and disrupts the community. Compared to the Required moderation process, this process is less effective in avoiding spam and abusive content. Required: Required moderation is the best way to combat spam and abusive content because the content is sent to the moderation before it’s made public in the community. This also protects your community’s reputation and creates a safe space for your members by ensuring the appropriate content is posted in the community. However, this process relies on additional resources to review the content, which may delay making the content public. This can disappoint members who want their content to be made public quickly. Set content moderation defaults at community level Sign in to the community as an Admin. Open the Account menu and go to Settings > Features. Select Moderation. The Moderation Types settings displays spam and content moderation settings. Here, you can set default moderation types for discussions, ideas, replies or comments on discussions, blog posts, knowledge base articles, events, and media. The screenshot below displays the Moderation Types, numbered for clarity. Select Edit for any of these options. A window to edit the moderation type opens. From here, you can: assign the moderation type for all members override this setting for specific roles with another moderation type value specify the roles that will bypass moderation The following is an example for moderating discussions and replies. The Community moderation type field for discussions and replies by all members falls under the Selective moderation type. This content is hidden until reviewed and approved. The Role-based Override field is set to Required for the roles selected in the Apply only to the following roles field. Discussions and replies by members with these roles are made public but go through moderation review. Roles added to the Exclude Roles field automatically bypass any moderation action. Similarly, you can set default statuses for other content types at the community level. Set content moderation defaults at category, group, or board levels The Moderation Types set at the community level are inherited to the category, group, and board levels. You can override these options at various levels as needed. Based on the inheritance, the settings applied at different levels are inherited to child places from their parent levels. For example, the content moderation defaults set at category or group levels are inherited to their child places. Learn more about setting inheritance. Let’s look at an example in which you want to set content moderation defaults at category level. To set content moderation defaults at category level: Open the Account menu and go to Settings > Community Structure. On the Community Structure page, select the category where you want to set the content moderation defaults. In the category settings, go to the Moderation section and set Content moderation types for content review as required. When you’ve adjusted a setting for a child place, a PARENT OVERRIDE indicator is displayed next to that setting for the child place to indicate that it overrides the settings of its parent. Similarly, you can set content moderation defaults at the group and board levels. Based on these board-level settings, when members post content on the community, the content is immediately routed to the Moderation for review. When a board is set to Required moderation and members post content on this board, a confirmation message is displayed on the post indicating that post will be published as soon as it is approved from moderators: From the Moderation tab, moderators can review content for appropriateness. They can then approve or reject it, and also message authors of the posts. Learn more about moderating content. Note: it is not possible to set different moderation levels for comments(or replies) and main posts Grant permissions to moderate content Moderation permissions should be granted only to roles assigned to trusted individuals. To manage this permission: Navigate to Admin > Settings > Users > Roles and Permissions. In the row of the role for which you want to manage this permission, select the Options menu and then Edit. In the Permissions area, below Moderation, locate Moderate Content. Select Grant or Deny as required.About Content permissions
You can adjust permissions related to content at the community, container (category & group), and board level. Some permissions are set to Deny by default while others are set to Grant by default. At the container level and the board level, permission defaults and role permissions are inherited from the parent level. In those cases, the Inherit button is displayed in green to indicate that the permission was set to Grant at the parent level or red to indicate that the permission was set to Deny at the parent level. As an admin, you can manage these permissions. To manage content-related permission defaults at the community level: Note: To manage this permission at a lower level, go to the [Place] Permissions page and edit the permission defaults for that level. To manage this permission for a particular role, go to the [Place] Permissions page at the desired level of the community and edit the permissions of the individual roles. Go to the Roles and Permissions page for the community. Beside Community Permissions Defaults, select Edit. Review permissions in the following areas: Blogs Content Events Ideas Knowledge Bases Select Deny or Grant as required. Unless you have specified different permissions for certain roles or levels below the community level (a category, group, or board), these selections affect all members of the community. Content permissions While Forum permissions are granted by the Content permissions, Blogs, Event Boards, Ideas boards, and Knowledge Bases have distinct permission sections for content type-specific tasks. The Content permissions are provided for general content access and tasks and relate to all content types. Follow the links in the table below to learn more about the tasks granted by these permissions. Permission Default Related permissions in content type sections Read discussions and content Grant Blogs: Read posts and Read comments Ideas: Read ideas and comments Reply to discussions and content Grant Blogs: Comment on posts Events: Comment on events Ideas: Comment on ideas Knowledge Bases: Comment on articles Start discussions and new content Grant Blogs: Start new posts Events: Post new events Ideas: Post new ideas Knowledge Bases: Create, edit, publish, and manage articles Edit own posts Deny Blogs: Edit own published posts Events: Edit own events Ideas: Manage ideas and comments Knowledge Bases: Edit own published articles Edit any post Deny Blogs: Edit any published post Events: Edit all events Ideas: Manage ideas and comments Knowledge Bases: Edit any published article Move content Deny Blogs: Manage any posts and Manage own posts Delete own post Deny Blogs: Manage own posts Events: Delete own events Knowledge Bases: Delete own articles Delete any post Deny Blogs: Manage any posts Events: Delete all events Ideas: Manage ideas and comments Upload file attachments Deny Embed external content Grant Turn on link hyperlinking Grant Use simple HTML in posts Grant Use advanced HTML in posts Deny Use full HTML in posts Deny Make content read only Deny Post read-only content Deny Bypass moderation Deny Blogs: Bypass comment moderation Events: Bypass comment moderation Ideas: Bypass moderation Knowledge Bases: Bypass comment moderation Related topics: About Aurora Community site structure About Aurora Content Types
Date Limit in Bulk API v2 and Error with 7-Day Intervals
Hey everyone, I have a quick question about the Date Limit in Bulk API v2. I'm trying to pull data for the last 24 months, but I found that Khoros seems to have a date limitation. Is it true that you can only pull data for either 7 days or 30 days at a time? I think I can only pull data for 7 days—any chance we can change it to 30 days? Another issue I'm running into is when I try to loop through the 7-day intervals for the past 24 months, I get this error: "Error DataSource.Error: Web.Contents failed to get contents from 'https://api.lithium.com/lsi-data/v1/data/export/community/logrhythm.prod?fromDate=20230401&toDate=20230430' (400): Bad Request" Can anyone share how you worked around the date limitation? I was looking at the API documentation, but didn’t find much that helped. Thanks!
