Added support for migrating notes from Simple Calendar

[Arctis-Fireblight]

Fixes #14
Fixes #17

Summary by CodeRabbit

• New Features
  • Adds legacy calendar import support so notes from the older format are detected and handled.
  • Automatically converts and migrates legacy entries to the current format during import, preserving calendar associations.
  • Ensures imports create, update, or recreate entries as needed to avoid duplicate or mismatched notes.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a legacy module name constant and updates calendar import logic to detect and convert notes stored under the legacy module flag to the new module flag, adjust sheet class and calendarId, and handle create/update decisions for converted entries.

Changes

Cohort / File(s)	Summary
Backward compatibility constant src/constants.ts	Added exported constant LegacyModuleName = "foundryvtt-simple-calendar" to provide a legacy module identifier.
Calendar import & note conversion src/classes/applications/configuration-app.ts	Import handling now reads noteData from flags[ModuleName] or flags[LegacyModuleName]. Introduced isConverted to detect legacy-origin notes, convert legacy flags to ModuleName, set ModuleName.NoteSheet, clear legacy flags, ensure journalEntryData.flags[ModuleName].noteData.calendarId matches calendarId, and update creation vs update logic to account for converted entries and legacy cleanup.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Added support for migrating notes from Simple Calendar' clearly describes the main change in the PR, which adds support for migrating notes from legacy/older versions of Simple Calendar by handling both new and legacy module name formats.
Linked Issues check	✅ Passed	The code changes fully address the linked issues: Issue #14 requires checking and correcting mismatched folder IDs during config restoration, and Issue #17 requires importing notes from legacy formats like the CarlosFdez fork. The PR adds LegacyModuleName support and implements conversion logic to read noteData from both legacy and new module formats, reconstruct entries with correct metadata, and handle both creation and updating scenarios.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with the PR objectives: adding LegacyModuleName constant and implementing migration logic in configuration-app.ts to support importing notes from legacy Simple Calendar versions. No unrelated changes detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In @src/classes/applications/configuration-app.ts:
- Around line 1858-1869: When converting legacy entries, avoid a null-pointer
and remove the redundant reassignment: ensure journalEntryData.flags["core"]
exists before setting its sheetClass (create journalEntryData.flags["core"] =
journalEntryData.flags["core"] || {} ), and remove the unnecessary else branch
that does journalEntryData.flags[ModuleName].noteData = noteData since noteData
was just read from that path; retain the logic that copies flags from
LegacyModuleName into ModuleName and then clears LegacyModuleName, and still
update journalEntryData.flags[ModuleName].noteData.calendarId = calendarId.
- Around line 1870-1876: The current create-vs-update check incorrectly treats
isConverted as a reason to create a new JournalEntry, which can attempt to
create a document with an existing ID; remove isConverted from the create
condition so that you only call JournalEntry.create when
noteImportedIntoDifferentCalendar is true or
game.journal.has(journalEntryData._id) is false, and otherwise call
game.journal.get(journalEntryData._id)?.update(journalEntryData); keep the
existing keepId logic (keepId: !noteImportedIntoDifferentCalendar) as-is since
conversion of flags is already applied to journalEntryData before this decision.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3867f99 and 5bbbe9a.

📒 Files selected for processing (2)

• src/classes/applications/configuration-app.ts
• src/constants.ts

🧰 Additional context used

🧬 Code graph analysis (1)

src/classes/applications/configuration-app.ts (3)

src/classes/notes/note-stub.ts (1)

• noteData (79-85)

src/constants.ts (2)

• ModuleName (5-5)
• LegacyModuleName (10-10)

src/classes/index.ts (1)

• NManager (13-13)

🔇 Additional comments (2)

src/constants.ts (1)

6-10: LGTM! Clean backward compatibility addition.

The LegacyModuleName constant is well-documented and appropriately placed alongside ModuleName. This will enable the import logic to recognize notes from the original Simple Calendar module.

src/classes/applications/configuration-app.ts (1)

12-12: LGTM! Import added for backward compatibility.

The LegacyModuleName import is correctly added to support the legacy module flag handling in the import logic below.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @src/classes/applications/configuration-app.ts:
- Around line 1864-1868: The code sets journalEntryData.flags["core"].sheetClass
without ensuring journalEntryData.flags["core"] exists, which can throw; update
the block inside the isConverted branch (where ModuleName and LegacyModuleName
are used) to ensure journalEntryData.flags and journalEntryData.flags["core"]
are initialized (e.g., create an empty object if missing) before assigning
flags[ModuleName], setting core.sheetClass to ModuleName + ".NoteSheet", and
clearing flags[LegacyModuleName].

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5bbbe9a and 515af60.

📒 Files selected for processing (2)

• src/classes/applications/configuration-app.ts
• src/constants.ts

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: Arctis-Fireblight
Repo: Fireblight-Studios/foundryvtt-simple-calendar PR: 20
File: src/classes/applications/configuration-app.ts:1870-1876
Timestamp: 2026-01-08T08:30:38.842Z
Learning: In the SimpleCalendar Reborn fork, when importing journal entries from the legacy "foundryvtt-simple-calendar" module that exist in the current world, the maintainer prefers to create new journal entries with new IDs rather than updating in-place, to avoid potential issues with "dirty" legacy configuration data.

📚 Learning: 2026-01-08T08:30:38.842Z

Learnt from: Arctis-Fireblight
Repo: Fireblight-Studios/foundryvtt-simple-calendar PR: 20
File: src/classes/applications/configuration-app.ts:1870-1876
Timestamp: 2026-01-08T08:30:38.842Z
Learning: In the Fireblight-Studios/foundryvtt-simple-calendar fork, when importing journal entries from the legacy 'foundryvtt-simple-calendar' module that already exist in the world, prefer creating new journal entries with new IDs instead of updating existing ones. This avoids potential issues with lingering or 'dirty' legacy configuration data. Apply this approach specifically in the configuration/import logic (e.g., in src/classes/applications/configuration-app.ts) and ensure that existing entries are left untouched unless a mechanism explicitly clones and re-links references.

Applied to files:

• src/constants.ts
• src/classes/applications/configuration-app.ts

🧬 Code graph analysis (1)

src/classes/applications/configuration-app.ts (3)

src/classes/notes/note-stub.ts (1)

• noteData (79-85)

src/constants.ts (2)

• ModuleName (5-5)
• LegacyModuleName (10-10)

src/classes/index.ts (1)

• NManager (13-13)

🔇 Additional comments (5)

src/constants.ts (1)

6-10: LGTM! Clean backwards compatibility constant.

The addition of LegacyModuleName is well-documented and follows the existing code patterns. This constant appropriately supports migration from the original "foundryvtt-simple-calendar" module.

src/classes/applications/configuration-app.ts (4)

12-12: LGTM! Import added for legacy module support.

The import of LegacyModuleName is necessary for the note migration logic implemented below.

---

1858-1863: LGTM! Solid legacy format detection logic.

The code correctly:

• Retrieves noteData from either new or legacy module flags using optional chaining
• Guards against missing noteData
• Detects legacy entries before any modifications occur
• Identifies when legacy entries exist in the current world for proper handling

Based on learnings, the approach of detecting and handling legacy entries separately is appropriate.

---

1872-1882: LGTM! Create/update logic correctly implements migration strategy.

The branching logic properly handles three scenarios:

1. Legacy entries that exist: Creates new entries with new IDs to avoid dirty configuration data (aligns with learnings)
2. Notes imported to different calendars or missing entries: Creates entries, using keepId appropriately based on whether the calendar changed
3. Existing non-legacy entries: Updates in place

The check for noteImportedIntoDifferentCalendar at line 1876 correctly uses the value computed at line 1860 before the calendarId was modified, ensuring accurate detection.

Based on learnings, this approach of creating new entries for legacy imports is the preferred strategy.

---

1870-1870: The code is already properly defensive about the noteData structure. At line 1858, the code explicitly attempts to retrieve noteData from the expected location (flags[LegacyModuleName]?.noteData), and line 1859 guards the entire block to ensure noteData exists before proceeding. When the conversion happens at line 1865, the entire legacy flags object is copied, which includes the verified noteData. No risk exists at line 1870.

Likely an incorrect or invalid review comment.