Blog Post

Release Notes
3 MIN READ

Khoros Communities 22.3 Release

AshaC's avatar
AshaC
Khoros Staff
3 years ago

22.3 is a minor release. As communicated earlier, minor releases contain defect fixes and minor enhancements. Minor releases are not made available in production by default. To request an on-demand upgrade, contact Support.

Content

Enhancements

API Updates

Bug Fixes

Enhancements

Spam Detection Using Honeypot Fields

With this release, we’ve enhanced spam detection experience with the Honeypot fields. These are hidden fields in forms where there is a possibility of a bot entering information. If these fields have values, it means that they were detected by a bot, and such posts are flagged as potential spam.
We have introduced Honeypot fields to the following editor forms: Forum posts and replies, TKBs, blogs, comments, ideas, Q&As, and product reviews.

Note: This enhancement is available by default on communities on version 22.3 and later and with spam management turned on. No other admin action or changes are required. 

Learn about our spam management tools and how to manage content in the Spam Quarantine.

API Updates

  • We have updated the messages collection to honor the Hide messages in this board from List option for a particular board. If you have enabled this option for a particular board, the messages will not appear in the response of a LiQL query. See messages collection.
    Note: This change could impact any customizations created in partnership with our services team that leverage hidden fields, so you should review these areas.
  • We have removed the mandatory board.id constraint from the content_workflow.state and visibility constraints in the messages collection. This is supported in Blog V3.1 and TKB V4.1 version.
  • We have added a new field latest_version in the messages collection to fetch the latest version of the published articles and the draft articles through a LiQL query. See latest_version in the messages collection.

You Found It! We Fixed It!

  • In the 21.12 Release, permissions set for a role at a category level overrode permissions set at a lower level. This issue is fixed.

  • There was an issue with kudos metrics for communities that had the Grant kudos on TKB articles permission set to No one and had customized to receive kudos on TKB articles and threads.
    The issue was that when an article was kudoed, an author's Net Kudos Metrics did not increase. But, if this kudo was revoked, the author’s kudo count decreased. Moreover, if an article was kudoed and then revoked repeatedly, the member’s Net Kudo Metrics could display a negative value.
    This calculation issue has been fixed. Now, on communities with this configuration, kudo actions on TKB articles are not considered in an author's Net Kudo Metrics calculation.

  • We have fixed the issue where another member could sign you out of the community by abusing the close account functionality. 

  • We have fixed the issue where event comments could not be moved to a different discussion board using the Move message option. 

  • We have fixed the issue where the product search dropdown persisted even after a search was completed and a message was posted.
  • We have fixed a cookie-related issue that did not render community pages in a selected language. 

  • The issue where some of the Events strings are not localised is now fixed. 

  • Sometimes the auto-title option to add a link in messages or posts did not work. This issue is fixed.

  • The issue where the page did not open after you clicked the hyperlinked text of images is fixed. 

 

Updated 7 months ago
Version 4.0

8 Comments

  • AshaC , the honeypot changes look really interesting! A few QQ's 

    1. Is there any action required by Admins to enable or implement this? Do I need to make any changes to my skin?

    2. Is there reporting offered to see how much the honeypot is catching?
  • AshishKe's avatar
    AshishKe
    Khoros Alumni (Retired)
    3 years ago

    Hi tyw , this enhancement will be available to communities which have spam management turned on, once they upgrade. No admin action or changes are required. 
    I will check on the reporting with our spam check tool provider and get back to you. 

  • AshaC ,

     

    The honeypot fields sound interesting. Is there any possibility a real user could end up in them? Are they in the tab stops for keyboard navigation? Has this change been tested to make sure it doesn’t affect accessibility compliance?

     

    Also is there any word when the invite to group by email feature is going to land?

  • AshishKe's avatar
    AshishKe
    Khoros Alumni (Retired)
    3 years ago

    allensmith81 Honeypot field is a hidden field and real users will not end up in it. Also it wouldn't affect keyboard navigation and accessibility compliance. 

    We are doing a beta release for the group hub - invite by email feature and will get in touch with you. 

    cc NarendraG GayathriS 


  • AshaC wrote:
    API Updates
    • We have updated the messages collection to honor the Hide messages in this board from List option for a particular board. If you have enabled this option for a particular board, the messages will not appear in the response of a LiQL query. See messages collection.
      Note: This change could impact any customizations created in partnership with our services team that leverage hidden fields, so you should review these areas.
     

    Is there any way to force them to show using restadmin? Feels like this went too far in the other direction now.

  • JavidH's avatar
    JavidH
    Khoros Staff
    3 years ago

    PerBonomi May I know what you mean by "Went too far in the other direction now" as the context here is not clear?  I would also like to know what you expect from the functionality?

     

  • JavidH it seems to be a common thing with developers (and definitely not only Khoros) to make choices for users.

    At some point someone asked or decided to have this feature, and not have the API surface items when the board is marked as don't show content.

    But look at how the API typically works now. If I use a rest call I get information that's available to the current user. If I use a restadmin call I get all the information, regardless of who the user is.

    So why not keep this behaviour for this feature now? Give users (us, your customers, in this case) a choice:
    Instead of "turning it off" completely and taking away the choice from those users who liked it just the way it is, add a simple constraint for use in the query, or something to that effect.

    SELECT * FROM messages WHERE board.id = '<board_id>' AND board.hide_items = true/false/either