Blog Post

Release Notes
14 MIN READ

Khoros Communities 21.10 Release

AshaC's avatar
AshaC
Khoros Staff
4 years ago

Content

New Features

Bulk content archive (Early Access)

Enhancements

Security Announcement

 API Updates

 You Found It. We Fixed It.

New Features

Bulk content archive (Early Access)

We are happy to announce that we’ve extended the Content Archive feature to include support for archiving content in bulk. 

With the initial Content Archive release, you could archive only one article at a time. With bulk archive, you can archive multiple articles at once, making it easier to keep your content organized and up-to-date. 

With bulk archive, you can:

  • Specify criteria to search for specific community content.
  • Review the matching content and select all matching results or select one or more specific articles from the list.
  • Archive the selected posts in bulk.

Enablement

To be considered for the Early Access (EA) program, contact your CSM. If selected, your CSM will work with the Support team to enable the feature. 

Once enabled, you can turn on/off the feature from the Admin panel. Go to ADMIN > Mod Tools > Content Archive > Turn on content archive. 

Note

  • If the Bulk Content Archive has not been enabled for your instance and the admin setting Mod Tools > Content Archive> Turn on content archive is turned on, you can archive only one content at a time. 
  • You can only restore or unarchive posts one at a time from the Archives page. There is no option to unarchive posts in bulk.   
  • All bulk archived content is moved to your community’s Archive Page

Check out this video to get an overview of the Bulk Archive feature. The video shows how you can bulk archive content from a TKB board with articles created at least one month ago, with no more than two views and no replies in the past one month.

1. Click the Archives link under the Community dashboard on your community home page

Step 1 image

2. Hover the Options menu

Step 2 image

3. Click Bulk Archive

Step 3 image

4. You will land on the Bulk Archive tool page.
Choose from where you want to archive content.

Step 4 image

5. In this example we choose Hi-Fi Products

Step 5 image

6. Select the type of posts you want to archive.

Step 6 image

7. In this example we choose TKB

Step 7 image

8. Select how old the posts that you want to archive are.

Step 8 image

9. In our example, we select posts that were created at least 1 month ago.

Step 9 image

10. Enter a valid number for Maximum Views for the posts that you want to archive. This will enable the In the Past dropdown.

Step 10 image

11. In this example, we enter 2 

Step 11 image

12. Select a timeframe for the views.

Step 12 image

13. In this example, we select 1 month, which means that the posts must have had a maximum of only two views in the past one month.

Step 13 image

14. Select a timeframe for which the posts have not had any replies within the time frame selected in the Created At Least and In the Past dropdowns.

Step 14 image

15. in this example, we select 1 month, which means that the posts have had no replies in the past 1 month.

Step 15 image

16. In our example we leave the Author filter empty Click Search.

Step 16 image

17. A row is added to the Job table as shown. The STATUS column shows that the job is currently searching the community for the filters submitted.

Step 17 image

18. You must refresh the Bulk Archive page to check the STATUS change of the job.

The STATUS changes to Ready to archive when the search completes and has fetched results.

Click Ready to archive.

Step 18 image

19. You will land on the Search Results page, which displays the posts retrieved for the job submitted. 

From here, you can either archive a few or all posts retrieved.

Step 19 image

20. If you want to archive only a few posts, select only those posts.
The number of posts you select are displayed.

Step 20 image

21. Click Archive Selected.

Step 21 image

22. Click Next.

Step 22 image

23. Click Archive.

Step 23 image

24. The selected post is queued for archival.

Step 24 image

25. If you want to archive all posts in one go, click Archive All.

Step 25 image

26. Click Next.

Step 26 image

27. Click Archive.

Step 27 image

28. All posts are queued for archival. 

Step 28 image

29. Scroll up and click Bulk Archive.

Step 29 image

30. The STATUS column for this job now shows that all posts are archived to the community's Archive page.

Step 30 image

Click the icon in the top right corner before you begin, for best experienced in Full Screen. 

1. On your community page, select the discussion board from where you want to bulk archive. 
In our example we select a TKB board.

Step 1 image

2. You will land on the selected board page.

Step 2 image

3. Hover over the Options menu.

Step 3 image

4. Click Bulk Archive

Step 4 image

5. Since you landed on this page from the TKB board, the values for Location and the Type of Post are pre-selected.

However, you can always choose a different Location and Type of Post from here.

Step 5 image

6. Select how old the posts that you want to archive are.

Step 6 image

7. In our example, we select posts that were created at least 1 month ago.

Step 7 image

8. Enter a valid number for Maximum Views for the posts that you want to archive. This will enable the In the Past dropdown.
In this example, we enter 2

Step 8 image

9. Select a timeframe for the views.

Step 9 image

10. In this example, we select 1 month, which means that the posts must have had a maximum of only two views in the past one month.

Step 10 image

11. Select a timeframe for which the posts have not had any replies for.

Step 11 image

12. In this example, we select 1 month, which means that the posts have had no replies in the past 1 month.

Step 12 image

13. In our example we leave the Author filter empty

Step 13 image

14. Click Search

Step 14 image

15. A row is added to the Job table as shown. The STATUS column shows that the job is currently searching the community for the filters submitted.

Step 15 image

16. You must refresh the Bulk Archive page to check the STATUS change of the job.

The STATUS changes to Ready to archive when the search completes and has fetched results.

Click Ready to archive.

Step 16 image

17. You will land on the Search Results page, which displays the posts retrieved for the job submitted. 

From here, you can either archive a few or all posts retrieved.

Step 17 image

18. If you want to archive only a few posts, select only those posts.
The number of posts you select are displayed.

Step 18 image

19. Click Archive Selected

Step 19 image

20. Optionally, enter the URL of the related content. When you attempt to view archived content (via a permalink or bookmark) you will be directed to this content.
In our example, we will leave this field empty.
Click Next

Step 20 image

21. Click Archive

Step 21 image

22. The selected post is queued for archival.

Step 22 image

23. If you want to archive all posts in one go, click Archive All.

Step 23 image

24. Click Next

Step 24 image

25. Click Archive

Step 25 image

26. All posts are queued for archival. 

Step 26 image

27. Scroll up and click Bulk Archive.

Step 27 image

28. The STATUS column for this job now shows that all posts are archived to the community's Archive page.

Step 28 image

https://www.iorad.com/player/1877100/Bulk-content-archive

https://www.iorad.com/player/1868612/Bulk-content-archive

 

Related articles:

Enhancements

Granular permissions to edit published blog articles

Prior to this release, there was no way to restrict members to only edit published blogs. Members had to be granted the “Manage own article”  or “Manage all articles” permission to edit blogs after they are published. This enabled members with these permissions to perform other content actions (delete, move and so on). 

With this release, we introduce two new permissions that enable members to only edit published blogs, and then take them through the publishing workflow process.

  • Edit my published blog posts: This permission is tied to the BlogAuthor role. Members with the BlogAuthor role can edit their published blogs and send the edited version for review. 
  • Edit all published blog posts: Members with this permission and the Start new articles permission can edit their blogs and those published by other members and send the edited version for review.

Note

  • You must be on Blogs version 3.1 to use these new permissions. Go to Studio > Features and select 3.1 for the Blog version. 
  • Once you have updated to Blogs v3.1, you must deny Manage own articles permission in the BlogAuthor role. BlogAuthors will have Edit my published blog posts permission by default.

Related articles:

Allow Co-Authors to edit published Blogs and TKB articles

Co-Authors of Blogs and TKB articles can now edit published articles. To do this,

  • Co-Authors of blogs must have the Edit my published blog posts permission.
  • Co-Authors of TKBs must have the Edit my published TKB posts permission.

Note

  • For Blogs, you must be on Blogs version 3.1 to use these new permissions. Go to Studio > Features and select 3.1 for the Blog version. 
  • For TKBs, you must be on TKB version 4.1 to use these new permissions. Go to Studio > Features and select 4.1 for the TKB version. 

Userid field added to Bulk Download Member Data report

With this release, we are adding the "Userid" field to the "Bulk Download Member Data" report. This field retrieves members' community userid and helps community managers identify the partially registered users who registered without a username.

Learn more about community member metrics

Security Announcement

As part of our efforts to continuously improve the security of our applications, Khoros will be upgrading our Web Application Firewalls (WAFs) for all customers over the next few months. These advanced WAFs provide enhanced capabilities that will enable us to better prevent bad requests from hitting applications earlier in the process, thereby improving the stability, reliability, and security of your communities.

While the rules and filters have been vetted and tested, due to the nature and customizability of the Community platform, there is a small risk that there could be some level of unexpected impact. Issues caused by the WAF could result in end-users receiving a 403 forbidden response to an operation. Contact Support if you see this behavior and provide as much detail as possible about the action you were taking and the timing of that action (including timezone information).

The change will first be rolled out to all stage instances and after a few weeks, we will roll out changes to production instances in batches.

API Updates

Bulk Data API v2.0

We are happy to announce the launch of Bulk Data API v2.0 with this release. The Bulk Data API v2.0 brings more user-actions and associated fields along with the existing actions and fields. 

Note: This new version will be available on November 8, 2021. 

Bulk Data API now includes this information:

  • Subscriptions
  • Private messaging
  • Idea status change
  • Event discussion style
  • Group hub interactions
  • 'Me too' user action
  • Product associations
  • Search metric enhancements
  • TKB helpfulness rating
  • Archival action
  • User Rank changes

The earlier version, v1.0, is still available. We will announce the deprecation of v1.0 in a future Community Release Notes. 

There are schema changes associated with Bulk Data API v2.0, and fields have also undergone re-ordering. We recommend updating the data store according to the schema changes before querying Bulk Data API V 2.0.

The new version supports exporting data belonging to past time ranges. 

Note that, these newly added action keys and associated fields will be fully available for date ranges post Nov 8, 2021. Which means that, when data for a past time range is pulled using Bulk Data API v2.0, all the currently available action keys and corresponding fields will be present. However, the newly added action keys and associated fields may not be fully available for past date ranges. 

For detailed information on Bulk Data API v2.0 action keys and fields, refer to the Bulk Data API v2.

Bulk content archive (EA)

With the introduction of the Bulk Content Archive feature, we also provide Bulk Content Archive APIs to archive content in bulk. 

Use these APIs to:

  • Create bulk archive processes
  • Retrieve details on currently running archiving processes 
  • Get the number of posts retrieved for the search filters applied
  • Retrieve all results
  • Delete and cancel a bulk archive process

To learn more, see bulk content archive and the archive bulk content use case.

Allow co-authors to edit published articles 

As mentioned earlier, Co-Authors of Blogs and TKB articles can now edit published articles. We also introduce APIs to achieve the same. All permissions and versions changes are applicable to use APIs, as mentioned in this section.

To learn more about these APIs, see Edit blog and KB articles after publication

Contributor types accessible through LiQL

The current API to retrieve the contributors for TKBs and blogs returns both the co-authors and contributors together. With this release,  we introduce a new constraint to list the co-authors and contributors separately. 

This new constraint, called messages_contributed.contributor_type, is added to the user object with two acceptable values: 

  • co-author
  • contributor

Learn more about the messages_contributed.contributor_type.

Attachments in Private Message

We have updated the threaded private message POST/notes_threads with the attachments field.

You Found it. We Fixed it!

General Fixes

  • We have fixed the issue where the RSVP links to No and Maybe were missing for languages other than English in Events version 1.2. This issue has been fixed on both the main page of the event and in private messages.

  • Earlier, comments or replies in Blogs v3 made via Khoros Care or API v1 did not appear on the community page. We have fixed this issue.

  • We have fixed the issue where the search page displayed a misleading message saying “No search results found” even before entering a search keyword.

  • Earlier, the thumbnails for all videos uploaded before the migration from Ooyala to Brightcove were missing. This issue is now fixed. All videos uploaded before the migration are accessible.

  • The issue that the comment box for comment syndication did not load on the external website is now rectified.

  • The issue that topics from the community were not automatically escalated to salesforce is resolved.

  • In communities where the Search Subscription and Email Metrics is enabled, the “change and discontinue your search” link in the Search Subscription emails were redirected to an error page. This issue is now fixed.
  • The issue that, when Admins changed the "Any edits & comments on knowledge bases articles I subscribe to" settings under the Admin > Users > Notification defaults, they were not updated, is now fixed.

  • Earlier, in an SSO-enabled community that uses dual authentication where users can register using a non-SSO method or an SSO method, non-SSO users could register using an e-mail address associated with another account. Even though the system recognized that the e-mail was already associated with another profile, it still accepted registration. This issue is now fixed. Now, when non-SSO users register, they will continue to be informed that the e-mail they selected is already in use and registration is rejected.

  • Earlier, when users with appropriate permissions tried to fetch a post or a reply to a post marked as spam using APIs, they received a "Permission Denied" error message, which was misleading. This is fixed. Now, when they fetch such posts and replies, they will see a success message without the content.

Accessibility Fixes

  • Earlier, the community pages that used the “BoardBrowserListTaplet” and “NodeListTaplet” components had a clickable icon and an adjacent message subject link next to it which both led to the same page. Some customers didn’t want two different UI elements that served the same purpose. We have addressed this issue by introducing a Studio parameter called "disableIconLink" to enable/disable links on the icons for the "BoardBrowserListTaplet" and "NodeListTaplet" components. 

    By default, links on icons for these components are enabled.

    To disable the links on icons from Studio:

1. Go to Studio.
2. Choose the community page where you want to make these changes.
3.Click Switch to XML View on the top-right section.
4.Add the parameter disableIconLink="true" to the component with id="forums.widget.board-browser-list" for BoardBrowserListTaplet and id="nodes.widget.child-node-list" for NodeListTaplet component as below:

<component id="nodes.widget.child-node-list" disableIconLink="true"/>
<component id="forums.widget.board-browser-list" disableIconLink="true"/>
  • The issue where the screen reader did not read out the information about the pagination controls when users entered, left, or navigated within a pagination component is now resolved. 

  • Previously, when community breadcrumb links were too long to fit on the page and the links were truncated with an ellipsis (for example, Community Name> TKB page name >name of the TKB arti…), the screen reader read out only the visible characters. This did not provide complete information to users. We have fixed this issue, and now the entire breadcrumb link is read.

  • A NVDA-specific screen reader issue where it announced incomplete information for the search filter buttons on the search edit field for Private Messages is now fixed.

  • On the Private Messenger page, the screen reader used to read out the "Inbox" and “Sent” buttons as "Show option button",  which was misleading.  This issue is now resolved. The screen reader now announces that they are drop-down menus with proper labels.

  • We have fixed the issue where the focus moved to multiple non-interactive elements on the page while navigating with the keyboard Tab key.

  • We have fixed the issue where the screen reader did not read out if the Additional Options or Teaser or SEO Options in the Post form were collapsed or expanded.

              

  • The issue where the screen reader read out the name of the file instead of the alternate caption provided for an image is now fixed. Now, when you upload an image with an alternate caption, the screen reader reads out the alternate caption.

  • Earlier, screen readers were unable to identify if a table on the community page was a “data” table or a “presentation” table. This was because the roles for both table types were set to "presentation".

    To fix this issue, we have introduced the “isTableRolePresentation” parameter that enables you to remove the role="presentation" attribute for the table from Studio. 

    For example, on the “Move Messages Page”, for the “move-messages-form” component, pass isTableRolePresentation="false", to remove the role="presentation" attribute. This means that the role is “table” for this component.  

     <component id="move-messages-form" isTableRolePresentation="false"/>

    Note:

    • The default value of “isTableRolePresentation” is “true”.
    • The default role is “presentation”.

    This parameter is available for these components:


    File Name

    Page Name

    Component Name

    AllDrafts.tml

    Blog Console Page

    BlogConsolePage

    RecentBlogArticlesTaplet.tml

    View Profile Page

    blogs.widget.recent-blog-articles

    MoveMessagesForm.tml

    Move Messages Page

    move-messages-form

    ThreadList.tml

     

    forums.widget.thread-list

    TaggedMessagesTaplet.tml

    Tag View Page

    tags.widget.leaderboard-messages

    tags.widget.leaderboard-messages-title

    tags.widget.leaderboard-messages-community-title

    tags.widget.my-recent-tagged-messages

    tags.widget.frequent-tagged-messages

    tags.widget.recently-tagged-messages

    ForumPage.tml

    Forum Page

    message-list

    MessageHistoryPage.tml

    Message History Page

    content

    MessageTrackerPage.tml

    Message Tracker Page

    MessageTrackerPage

    RecentPostsPage.tml

    Recent Posts Page

    post-list

    TagDetailPage.tml

    Tag Detail Page

    tag-list

    UnansweredTopicsPage.tml

    Unanswered Topic Page

    unanswered-list

    UnreadPostsPage.tml

    Unread Posts Page

    unread-list

    ForumsFilteredByLabelPage.tml

    Forum Filter by Label Page

    post-list

    GroupPage.tml (common)

    Group Page

    message-list

    TopMessagesLeaderBoard.tml

    Kudos Leaderboard Page

    tabs

    KudosUserPage.tml

    Kudos User Page

    KudosUserPage

    ProductMessageList.tml

    Product Page

    products.widget.product-message-list

    RecentQuestionsPage.tml

    Recent Questions Page

    question-list

    TkbHistoryViewList.tml

    TKB Article History Page

    history

    TkbPage.tml

    TKB Page

    message-list

  • We have fixed the issue where the color contrast between the “Close” button and the background was insufficient for low-vision users to see the icon clearly. Now, the contrast between foreground and background colors meets the WCAG 2 AA contrast ratio thresholds.

 

Updated 5 months ago
Version 10.0
  • SohilM's avatar
    SohilM
    Lithium Alumni (Retired)

    MarkSchwanke if you are an admin, in Blogs v3+, you should be able to view all the drafts (by all authors) in the dashboard and should be able to edit/publish too. 

  • I see we're looking into bulk archive, but there's a bug for arhive not working now.  Do we worry the bulk archive won't work either due to the bug?  

  • RahulHa  Here is the case number:  00358084 with a status of Bug Identified.  When I Archive a post, it isn't removed from the list of posts, but when you click on the article, it states it is archived.  When you navigate to Archives, it doesn't appear in the list.

  • SohilM I’m definitely an admin. but even members are not able to view their own drafts or edit their draft articles once they leave the compose page in version 3.0.  They can post or delete them from the draft articles page without viewing. But then they can’t edit or add on once published because version 3 doesn’t allow them to edit their own published articles either.  As the admin I’m not able to view their draft articles either in version 3.0  I too can post them for the user and then I can view and edit their articles after they’re published.  

    hoping 3.1 allows them to edit both draft and published articles and allow me a admin to see their draft articles as well. 

  • jamiemccardle strange. I reported the same behaviour on Tuesday, but for me the end result was that this problem is fixed by the system automatically after a short period. According to our further experience, this is true. Can you elaborate on this topic please?

  • nbalogh  MarkSchwanke The articles did eventually remove from the list after three hours, but didn't appear in Archives at that time.  It eventually did after 24 hours.  I worry testing a new Archive functionality when the feature has such a delay.  

    MarkSchwanke 

    We're on Blogs v3. Here is how we setup our Article Editors which allows them to edit their posts (we also added all posts edits), submit for review, but not publish.  This allos them to edit published articles, but not publish them.  It'll save as a draft.

     

  • SohilM's avatar
    SohilM
    Lithium Alumni (Retired)

    MarkSchwanke In Blogs v3, an author should be able to view all their drafts by default in the blog dashboard. Also, there is a permission 'view all drafts', that allows a member to view all drafts from all authors in a node in the dashboard. The permission is granted by default to BlogEditor, BlogPublisher roles and admins. Please refer to this article for more details on the dashboard.  

    Admins, should be able to take all actions (edit, submit for review, submit for publication, publish, schedule) on any draft in the dashboard. Also, Admins should be able to edit any already published article. 

    In v3, for Authors to edit an already published article, they would need either 'manage own articles' or 'manage any articles' permission. Since these permissions, in addition to edit capability, grant capabilities such as move, delete, edit other's comments etc, we introduced granular permissions for only edit in v3.1. 

    We introduced two new permissions, 'edit my published articles' and 'edit all published articles' in v3.1. Details listed in the release notes above

    If you still face the issue, please send me a private message, we will look into the issue. 


  • nbalogh jamiemccardle 

    Yes I was seeing that too.  If you look at the post right after archiving it doesn’t disappear from the lists right away but if you click on it it is archived and states that or redirects you if you provided a link.  Give it a little time.  I do find this behavior odd though and have to set reminders to double check to ensure it disappears from lists later.  I have also had people email me right after I archive something that still appears in the unanswered topics list and ask what’s wrong.  

     

  • SohilM I'll be sending you a private message.

    The closest configuration to what I want is:

    Blog Articles:

    • View all Drafts: Deny
      • Don't want people to see everyone else's drafts.
    • Start new articles: Grant
      • Want them to be able to make blog articles in the intended forum board.
    • Review Articles: Grant (Gives me the Publish/Post Button 🤔)
      • If I change to Deny the Publish button disappears. People should just be able to view their own drafts. I don't want them to have the Submit for review button. 
    • Publish Articles: Grant
      • So they can post their articles right away.
    • Read Articles: Grant
      • So they can read other people's blog articles
    • Manage any article: Deny
      • They shouldn't be able to do anything with any other member's article
    • Manage own articles: Deny
      • They shouldn't be able to modify other people's comments or delete their blog articles
    • Edit my published blog posts: Grant
      • They should be able to edit their posts to fix grammar errors
    • Edit all published Posts: Deny
      • They shouldn't be able to edit any one else's blog article posts
    • Manage All comments: Deny
      • They shouldn't be able to edit any comments on any blog article.
    • Manage comments on own articles: Deny
      • They shouldn't be able to edit any comments on their own article
    • Approve, recall or reject comments: Deny
      • They shouldn't be able to moderate comments in the blog board. Leave it to the moderators.
    • Bypass comment moderation: Deny
      • They are subject to all moderation based on community setting.
    • Comment on articles: Grant
      • They can comment on all articles in the blog board
    • Read Comments: Grant
      • They can read comments posted in the blog board without restriction.

    The above settings are closest to what I need for my community based on Blog Version 3.1. Ideally the "Submit for Review" button is hidden on the post page and the edit article post page as we don't need anyone to have their blog approved in the members' blog board. I'm confused why the Review Articles permission makes the Publish/Post button appear and disappear?