Feature Request

The Revision History pane is very confusing to read, because it displays information about multiple actions actions performed by multiple users. AK didn't unpublish the article, but in the first image it appears she did because that's what reads next to her icon. And we didn't think to expand the "Workflow history" button because it cuts off at "Workflow hi..." even though there's enough room for all the text to be visible next to the "Fork", "Delete", and "Open" buttons. Here's how we interpreted the information before we expanded the workflow history: In one "cell", it reads to the end user that AK forked v2 from v1 (correct), unpublished the article (incorrect), AND left the comment (incorrect). It also lists a date (this Tuesday) but that date doesn't represent the day the article was forked – it represents the day the article was unpublished. Yet the date is listed right next to "v2 forked from v1". Overall, this pane could use a lot of UX improvement. For example, why even hide the workflow history under a tab? it'd be nice to see all this history in one continuous scrollable pane without having to open dropdowns, in my opinion (not sure about other users). Or, have one pane for version history and a second pane for workflow history across all versions. I think I also saw another feature request where someone asked to increase the size of the text because it was too small. I would hope these changes could be on the higher priority side, because this feature has so many uses (auditing, collaboration, cross-referencing) that I'm sure users open this pane often, like myself. Thank you! :)

I have no manual control over the versioning system. If I want to save a restorable version before continuing with edits, I have to publish an article and then click "Edit". Based on the new "Recall" feature in Windows, I had the idea of a feature for manually saving article snapshots that can later be restored, but that aren't published. It's happened repeatedly that I made major changes to an article, but because we are still at the beginning and don't know what works and what doesn't for readers, I cannot be sure if the previous version wasn't the better one. In that case, before I begin edits, I imagine a "Create snapshot" button that allows me to manually save the article in its current state in case I want to restore it later.

We currently have a folder of articles that was duplicated and published in two separate KBs. This wasn't my decision, but we now need a way to compare these dup articles to see what content differs between them so they can be merged. It would be great, in the same way you have the compare versions feature, if you could select two articles from any workspace or folder, then select a version of those articles, then compare both those versions in the same interface that exists for revision history. I can see this having multiple use cases: 1) an article was cloned and published in a different workspace, and now both need to be compared, and 2) you have multiple workspaces for different versions of your product, and you need to compare v1 from one workspace to v2 of another. Thank you! :)

I would love to be able to generate a list of all the new articles published in a given time period, as well as the number of articles that were updated in the time period. Currently, you can only provide a list by publication date, but there's no way to determine whether it's a new or updated article, and any article that was updated again after the end of the time period is not included. That is to say, if I export a list of articles published in December 2022, what I get right now is only a list of what was published that month but not since then; if I have an article that I published in December but then updated in January 2023, it is not included in the December list. This would be very helpful for our reporting purposes, to allow us to know how many new and updated articles we're producing. Thanks for considering this request.

Open a published article in the portal and do the following: Click Edit. Navigate away from article. Come back to article. The light blue banner is no longer there and we do not see an option to invoke it.

It would be useful to be able to extract a PDF (or other format) copy of the comparison of different versions in the version history. This is because we have to get sign-off on changes to documentation from an external panel and we would like to be able to send them a copy of the comparison with all of the marked changes,

Any time the edit button is clicked, it creates a version. This adds to the noise. Sometimes, we may just want to copy a section of the article. It automatically creates a version. And becomes a mess in bulk operations. Instead, when the article is closed, if there is no change, the article must not be saved to create a new version. Only if there is some change made, should there be a version created. Our software has this ability. In fact if the user were to click Ctrl + Save... it returns a message saying no changes detected.

It would be great to have a similar functionality as Git-Rebase. Git rebase is a command used in Git version control systems to incorporate changes from one branch into another. Unlike merging, which creates a new commit to combine the changes of two branches, rebasing rewrites the commit history by moving or "replaying" commits from one branch to another. Keep our commit history tidy and easy to understand. Avoid cluttering our history with unnecessary merge commits. Reduce the likelihood of conflicts when merging branches. Make code reviews smoother by presenting changes in a logical order. Enable better collaboration by keeping everyone's work organized and up-to-date with the main branch.

When an article/category is cloned (also across workspaces), the respective revision history is lost! In some circumstances, this information would be interesting. There may be different approaches, for example, (a) option to clone with the complete history, (b) option to clone with at least the history comments, (c) include at least the info that it is a cloned article/category with a link to the original one (right now you cannot differentiate whether an article was cloned or created from scratch).

Please consider adding more details to the Article Revision or Article banner details to include a date the article was hidden to improve workflow efficiencies. The current options are not efficient, especially when through the maintenance of broken links. If an article that is hidden has a broken link, it still shows up on the report. If the article is extremely outdated,d there is no way to view this information other than using the Team Audit features when other team members have hidden the article from view. In this case, please navigate to Settings > Knowledge base portal > General > Team auditing > Now click on 'Events' filter > Then type Article visibility changed. Now you can export the events and confirm on which date the article was hidden. For smaller Knowledge teams, this is not an efficient workflow and is quite time-consuming. Perhaps a good place to add this visibility would be to the banner that is present on the Hidden article.