Protected note contents get rendered whenever it has child notes

[kpghostfox]

Description

When viewing a protected note (in my case Calendar) from an unprotected session, both the login form and note contents render. After further investigation, it appears that all note types except the ones from Other category are affected by this bug.

How to reproduce?

1. Create a new note of any type listed below
2. Create a child note (I've used a text node filled with gibberish)
3. Protect both notes
4. Restart Trilium

Example setup:

Expected results:

Only the login form shows

Observed results:

Both the login form and note contents render.

Affected note types

Text

Code

Grid

List

Calendar

Table

Geo Map

Presentation

Board

Text snippet

TriliumNext Version

0.102.1

What operating system are you using?

Other Linux

What is your setup?

Local + server sync

Operating System Version

Linux saturn 6.18.19 #1-NixOS SMP PREEMPT_DYNAMIC Thu Mar 19 15:08:51 UTC 2026 x86_64 GNU/Linux

Error logs

No response

[dosubot]

Hi @kpghostfox! I'm Dosu and I’m helping the Trilium team.

This is a confirmed bug that was already addressed in PR #9033, merged on 2026-03-12.

Root cause: Note rendering has two independent paths — getExtendedWidgetType() controls the main content widget, and hasNoteList() controls the child note list. The protection check (note.isProtected && !protectedSessionHolder.isProtectedSessionAvailable()) existed in getExtendedWidgetType() [1], but was missing from hasNoteList() in note_context.ts. This meant the login form rendered correctly, but the child note list still rendered behind it [2].

The fix added a protection guard to the hasNoteList() method so it returns false for protected notes when no protected session is active:

if (note.type === "book") {
    if (note.isProtected && !protectedSessionHolder.isProtectedSessionAvailable()) {
        return false;
    }
    // ...
}

The same PR also fixed a related issue where collection creation APIs (board, calendar, geomap, table) were not propagating isProtected to child notes — so children created in protected collections before this fix may themselves be unprotected [3].

Since you're on v0.102.1, you may not have this fix yet. It's worth checking whether a newer release includes it. However, looking at the researcher's findings, the fix for text/code notes with children may still be incomplete — the non-book path in hasNoteList() (which triggers when note.hasChildren() is true) doesn't appear to have the same protection guard added [4]. That could explain why you're seeing the issue across many note types beyond just book/collection types.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}