Bugs

We embed our knowledge base ( help.reveleer.com ) in our web app using the standard JS widget (helpjuice.min.js with #helpjuice_js_widget_content). When users browse to an article by clicking links in the KB, the parent page's URL hash updates as expected. When they open the same article from Swifty search, the article loads but the parent URL doesn't change. Users therefore can't bookmark or share the article, and a page refresh drops them back on the KB home page. Steps to reproduce Open embedded KB in a web app. Browse to an article via categories. The parent URL hash updates. Go back to the KB home page, search for something in Swifty search. The article loads in the iframe, but the parent URL doesn't update. What we found The parent hash is only set when questions_widget.js posts a message with a url. It does that from a delegated click handler: $(document).on("click", "a[target!='_blank']", ...). On page load it always sends url: "/", which helpjuice.min.js ignores. Swifty search draws its results inside a shadow DOM (#ai-search, attachShadow), and .swiftysearch__inner calls stopPropagation() on click. As a result, clicks on search results never reach the document-level jQuery handler, and no URL message is sent to the parent. HAR files and console logs for both cases are attached. Requests Can this be fixed so Swifty search result navigation notifies the parent page, the same way regular link clicks do? Sending the current path on page load would cover all ways of navigating. In the meantime, is it supported for us to add custom JS to our KB template that posts the current path to parent.socket on page load? Or do you recommend another workaround?

Since the switch to the new editor (which I do like a lot), bullets don't seem to format properly and what it shows me in the editor doesn't always match what's on the frontend. (Example: Editor will show a numbered list formatted properly but on the front end, the numbers will be completely wrong). I've also noticed that with Decision Trees in the new editor, headers are center-aligned whether I've formatted them that way or not (and I never use center-alignment).

Wrong initials on the Profile image. For example, User has First Name set as "Mahir" and Last name as "Tokic". However, the profile image shows as "MA" instead of "MT"

When reviewing and editing an article with an "Under Review" status, the status drop-down in the upper right corner of the Article Editor continues to pop open repeatedly after being closed. This obstructs the visibility of the article and impedes on productivity.

When we schedule an article to be published on a specific date, there's no indication of this in the editor so we don't know if it's scheduled or not. It just shows as a regular draft article.

When a user submits Article Feedback it doesn't get added in the Article Feedback section. Also, the Email Notifications is not sent.

When we add the first reviewer to an article it works as expected. However, if we try to add more reviewers, it doesn't work and we get a 422 error in the console.

The images look correct in the editor, but on the exported PDF and Word, they look distorted. There seems to be an issue with the image's height value—it doesn't automatically adjust when adding or resizing an image, which is causing the export issue. As a temporary workaround, we can manually decrease the height value of the image before exporting, and it should work as expected.

BUGS Voice overlaps The responses by text since the voice call was released have slowed down, and sometimes doesn't even answer. Other times it provides a no results message and if we ask it multiple times the same question, it finds the answer FEEDBACK The intro to the bot feels also feels a little long. A lot of "I'm thinking" "Let me look at our database" "Thank you for contacting the support team"...I know why you have it :) but anything you can do to cut some of that out so it doesn't feel like as much filler chat.

This is an issue that isn't made clear in the documentation, but Helpjuice does not provide per-user API keys. It only provides a single API key. This is a security issue that violates the best practice of least privilege. 1) API is always at admin level (so you can't assign a service account that is view only and limit API usage that way). 2) If you have multiple integrations, you should have a single API key for each one. This way if something goes wrong, or you need to terminate access, it can easily be done by removing the corresponding user. Atlassian's use of API keys is a good example of how it should be done.