Skip to content

fix: open the note editor from Write Note - #1286

Open
mvanhorn wants to merge 1 commit into
lfnovo:mainfrom
mvanhorn:fix/1252-write-note-dialog
Open

fix: open the note editor from Write Note#1286
mvanhorn wants to merge 1 commit into
lfnovo:mainfrom
mvanhorn:fix/1252-write-note-dialog

Conversation

@mvanhorn

@mvanhorn mvanhorn commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Description

Replace the coupled create/edit open-state calculation in NotesColumn with one explicit editor-open state and one optional selected note, following the controlled editor pattern used by TransformationsList. Route both the Write Note button and note-row editing through a small production handler that clears or sets the selected note before opening the existing NoteEditorDialog, and mirror onOpenChange directly while clearing selection on close. Add a focused NotesColumn interaction test that mocks the existing editor boundary and verifies the create path receives the current notebook ID with no selected note, opens on click, closes cleanly, and can be opened again; also preserve the edit path so the state cleanup does not regress row editing.

The notebook Notes column renders a Write Note button, but issue #1252 reports that clicking it produces no modal, console error, or network request. The production entry point is NotesColumn, which currently derives the editor's open state from both showAddDialog and editingNote and translates the dialog callback back into those states. The same repository already has a simpler working controlled-dialog pattern in TransformationsList, while the Notes column has no interaction test covering its create-note entry point. The note API and NoteEditorDialog creation behavior are already present, so the fix should stay within the column's dialog wiring.

Fixes #1252

Related Issue

Fixes #1252

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Code refactoring (no functional changes)
  • Performance improvement
  • Test coverage improvement

How Has This Been Tested?

With notes loaded, click Write Note and verify the existing note editor becomes open in create mode with the supplied notebook ID and no note selected.
With an empty notes list, click the same header action and verify create mode opens, proving the behavior is independent of whether a source or note already exists.
Close the create dialog through its onOpenChange(false) callback, then click Write Note again and verify it reopens without stale edit state.
Click an existing note row and verify the editor opens with that note; close it and then open Write Note to verify create mode does not retain the previously selected note.

Design Alignment

Which design principles does this PR support? (See VISION.md)

  • Privacy First
  • Simplicity Over Features
  • API-First Architecture
  • Multi-Provider Flexibility
  • Extensibility Through Standards
  • Async-First for Performance

Explanation:

Checklist

Not applicable to this change.

Code Quality

  • My code follows PEP 8 style guidelines (Python)
  • My code follows TypeScript best practices (Frontend)
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings or errors

Testing

  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I ran linting: make ruff or ruff check . --fix
    Not run: no test command resolved in this workspace, so nothing was executed to pass.
  • I ran type checking: make lint or uv run python -m mypy .
    Not run: no test command resolved in this workspace, so nothing was executed to pass.
  • With notes loaded, click Write Note and verify the existing note editor becomes open in create mode with the supplied notebook ID and no note selected. - With an empty notes list, click the same header action and verify create mode opens, proving the behavior is independent of whether a source or note already exists. - Close the create dialog through its onOpenChange(false) callback, then click Write Note again and verify it reopens without stale edit state.

Documentation

  • I have updated the relevant documentation in /docs (if applicable)
    Not run: no test command resolved in this workspace, so nothing was executed to pass.

Database Changes

  • I have created migration scripts for any database schema changes (in /migrations)
    Not run: no test command resolved in this workspace, so nothing was executed to pass.
  • Migration includes both up and down scripts
  • Migration has been tested locally

Breaking Changes

  • This PR includes breaking changes

Screenshots (if applicable)

Additional Context

Nothing beyond what is described above.

Pre-Submission Verification

Before submitting, please verify:

  • I have read CONTRIBUTING.md
  • I have read VISION.md
  • This PR addresses an approved Issue assigned to me, or it's a small obvious fix (typo, docs, tiny bug) that doesn't need one — ideas and features begin in Discussions; reproducible bugs begin in Issues
  • I have not included unrelated changes in this PR
  • My PR title follows conventional commits format (e.g., "feat: add user authentication")

Thank you for contributing to Open Notebook! 🎉

AI was used for assistance.

Review in cubic

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 2 files

Confidence score: 5/5

  • frontend/src/app/(dashboard)/notebooks/components/NotesColumn.test.tsx only partially exercises the editor lifecycle, so a regression when reopening the same or another note after onOpenChange(false) could go undetected; add an explicit reopen assertion to cover that path.
Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="frontend/src/app/(dashboard)/notebooks/components/NotesColumn.test.tsx">

<violation number="1" location="frontend/src/app/(dashboard)/notebooks/components/NotesColumn.test.tsx:100">
P3: The edit path is only exercised once. Test 3 clicks a note row (edit mode), closes the editor, then clicks Write Note (create mode) — it never re-opens the same/different note row after the `onOpenChange(false)` cleanup (`setEditingNote(undefined)`). Since the final `data-note-id` of '' would pass even if the close handler did not clear the selected note (Write Note's `handleOpenEditor()` also clears it), this test does not actually pin down the close-cleanup regression the PR claims to preserve. Add a step that re-clicks a note row after closing and asserts `data-note-id` is the note id again, so a regression in the edit path after cleanup is caught.</violation>
</file>

Reply with feedback, questions, or to request a fix.

Re-trigger cubic


fireEvent.click(screen.getByText(existingNote.title!))
expect(editor).toHaveAttribute('data-open', 'true')
expect(editor).toHaveAttribute('data-note-id', existingNote.id)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: The edit path is only exercised once. Test 3 clicks a note row (edit mode), closes the editor, then clicks Write Note (create mode) — it never re-opens the same/different note row after the onOpenChange(false) cleanup (setEditingNote(undefined)). Since the final data-note-id of '' would pass even if the close handler did not clear the selected note (Write Note's handleOpenEditor() also clears it), this test does not actually pin down the close-cleanup regression the PR claims to preserve. Add a step that re-clicks a note row after closing and asserts data-note-id is the note id again, so a regression in the edit path after cleanup is caught.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At frontend/src/app/(dashboard)/notebooks/components/NotesColumn.test.tsx, line 100:

<comment>The edit path is only exercised once. Test 3 clicks a note row (edit mode), closes the editor, then clicks Write Note (create mode) — it never re-opens the same/different note row after the `onOpenChange(false)` cleanup (`setEditingNote(undefined)`). Since the final `data-note-id` of '' would pass even if the close handler did not clear the selected note (Write Note's `handleOpenEditor()` also clears it), this test does not actually pin down the close-cleanup regression the PR claims to preserve. Add a step that re-clicks a note row after closing and asserts `data-note-id` is the note id again, so a regression in the edit path after cleanup is caught.</comment>

<file context>
@@ -0,0 +1,108 @@
+
+    fireEvent.click(screen.getByText(existingNote.title!))
+    expect(editor).toHaveAttribute('data-open', 'true')
+    expect(editor).toHaveAttribute('data-note-id', existingNote.id)
+
+    fireEvent.click(screen.getByText('close editor'))
</file context>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: "Write Note" button in a notebook does nothing (no modal, no console error, no network request)

1 participant