Skip to content

Issue 250 Folder Click Left Article Open

Ed Mozley edited this page Nov 7, 2026 · 1 revision

Clicking a folder left the open article on screen

Reported: #250 by Dr4inder, November 2026 Β· Fixed by: PR #251, also by Dr4inder Β· Module: Knowledge Β· Fixed in: the release after 4.10.0 (changelog #2741)


What you saw

  1. In Knowledge, open an article.
  2. Without pressing Back to list, click a different folder in the Folders panel on the left.

The folder highlighted and the address bar changed to ?folder=…, but the article stayed on screen. The folder's list had loaded behind it and stayed hidden, until Back to list showed it.

It is easy to miss. The highlight looks like the click worked, and it never happens from the list screen. You have to be reading an article when you click the folder.


What was actually wrong

selectFolder() in assets/js/knowledge.js is what every folder link calls: the left panel, the trail above the list, the folder cards and rows, and the folder row in an article's details. It set the folder, updated the address bar, and reloaded the tree and the article list. It never changed which screen was showing.

The screens are switched by showView(), which shows one of the list, the article and the editor. An open article had set it to the article. A folder click then loaded a new list into the hidden list view.


The fix

function selectFolder(value) {
    activeFolder = String(value);
    if (document.getElementById('articleDetailView').style.display === 'block') {
        showView('list');          // reading an article: go to the folder's list
    } else {
        syncArticleUrl('list');    // list or editor: stay, but keep the address bar right
    }
    ...
}
  • Reading an article β†’ the folder's list is shown. showView() also updates the address bar.
  • In the editor β†’ you stay in the editor. A folder click must never hide an unsaved draft. The folder is still selected and the address bar still follows it, as before.
  • On the list β†’ nothing changes.

No database change, nothing to run after upgrading.


Files changed

File Change
πŸ”΅ assets/js/knowledge.js selectFolder() returns to the list from an open article
πŸ”΅ knowledge/index.php knowledge.js?v=66
πŸ§ͺ tests/knowledge-folder-navigation.php new: runs the real selectFolder(), syncArticleUrl() and showView() in a headless browser

Review of PR #251

Verdict: merge, with one small change. The PR is small, it targets the cause rather than the symptom, and it thought about the editor case without being asked.

Merged by cherry-pick (169df3319), so the commit stays Dr4inder's.

Changed after merging (fbe13f5d1): the PR removed an existing ⚠️ comment explaining why syncArticleUrl('list') is called at all. That reason still applies to the editor branch, so the comment went back there.

Checked and left as it is:

  • currentArticle is not cleared when the list comes back. Every reader of it either checks which screen is showing (syncArticleUrl() only names an article on the article or editor screen) or is reset first (New sets it to null). Saving and archiving already return to the list the same way.
  • Every folder link is covered, because they all call selectFolder().
  • Testing on the visible screen (style.display === 'block') is safe: showView() is the only thing that shows the article, and it sets exactly block.

How it was proved. The PR's code was driven on the real Knowledge page, in a same-origin iframe in headless Chrome:

Did Got
Opened an article, clicked a folder βœ… that folder's list, ?folder=340, the article hidden
Opened an article, clicked Home βœ… the whole list, address cleared
Clicked New, typed a title, clicked a folder βœ… still in the editor, title kept
Browser console βœ… no errors

The same first step on the old code left the article showing with ?folder=340 in the address bar.

Not proven here: the PR's own test, tests/knowledge-folder-navigation.php, reported 6 passes on the contributor's machine. On the maintainer's Windows machine it did not finish - and nor did an existing test using the same browser helper (tests/support/ticket-workspace-browser.php). So that is the helper on that machine, not this test. The live run above covers the same three cases.


What this means for you

  • Clicking a folder while reading an article now takes you to that folder's list.
  • Clicking a folder while editing keeps you in the editor - nothing you have typed is hidden.

Related

FreeITSM

Getting Started

Modules

Multi-tenancy (planned)

Blue sky thinking

Bugs resolved

Links

Clone this wiki locally