[sh1vam31]

Fixes #107

If a note was set as the default template and later had its template tag removed, the plugin would silently fail or give a misleading error. It should instead inform the user that the saved default is no longer a template.

Fix

src/utils/templates.ts

• Added isNoteATemplate(noteId) — checks if a note still has the template tag
• Updated getTemplateFromId() to return null if the note is no longer a template

src/index.ts

• Both "Create note from default template" and "Create to-do from default template"
  commands now show a clear, actionable error message:

"The note set as the default template is no longer a template.
Please set a new default template via Tools → Templates → Default templates."

Testing

1. Created a note, tagged it as template, set it as the default template
2. Removed the template tag from that note
3. Clicked Tools → Templates → Create note from default template
4. The correct error message appeared
5. Re-added the template tag → default template worked normally again

[sh1vam31]

@nishantwrp, Kindly review this PR.

[alondmnt]

Thanks for tackling this @sh1vam31. The approach and error messaging look good for the tag-based workflow.

One issue: isNoteATemplate hardcodes a check for the template tag, but when TemplatesSource is set to "Notebook", templates live in a "Templates" folder and don't need that tag. Since getTemplateFromId is shared, this would cause notebook sourced default templates to be incorrectly rejected.

The fix should respect TemplatesSourceSetting for notebook source, check that the note is in a "Templates" folder instead of checking for the tag.

[alondmnt]

Following up on my earlier review, this is worse than I described, and my suggested fix was too narrow.

Putting the tag check inside getTemplateFromId also reaches index.ts:74-83, where both lookups returning null triggers clearDefaultTemplates. So a Notebook-source user who opens "Show default templates" gets their saved per-notebook config silently deleted, since their templates are untagged by design.

The underlying problem is that getTemplateFromId meant "load this note, null if I can't", and that cleanup path depends on that meaning. So rather than teaching isNoteATemplate about TemplatesSourceSetting, I'd move the check out of getTemplateFromId entirely and call it only from the two "create from default template" commands. That also avoids the same trap for tag-source users who genuinely untag a note. The error messaging in index.ts is good as is.

[sh1vam31]

Hi @alondmnt,

Thanks for the review! I've updated the PR based on your feedback:

Reverted getTemplateFromId: Kept its responsibility clean (checks note existence without forcing tag validation, preventing settings erasure in showDefaultTemplates).
Added isNoteATemplate: Implemented a source-aware check in src/utils/templates.ts supporting both Tag and Notebook template source modes.
Updated Handlers & Tests: Called isNoteATemplate inside default template command handlers and added unit tests covering both modes.
Merged master: Resolved branch merge conflicts and verified all 102 unit tests pass (npm run lint && npm test && npm run dist).
Ready for re-review when you have a moment.

[sh1vam31]

Hi @alondmnt,

I have resolved the merge conflicts with the latest master in src/utils/templates.ts.

All checks pass locally (npm run lint, all 105 tests in npm test, and npm run dist).
Ready for review.