strapi-plugin-magic-mail 2.10.6 → 2.10.7

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+## [2.10.7](https://github.com/Schero94/Magic-Mail/compare/v2.10.6...v2.10.7) (2026-04-21)
+
+
+### Bug Fixes
+
+* **email-designer:** prioritize templateReferenceId in findById() to match actual admin UI usage ([bcd7a4b](https://github.com/Schero94/Magic-Mail/commit/bcd7a4bd3b9640f8bc58694ec7a81fddb262245f))
+
 ## [2.10.6](https://github.com/Schero94/Magic-Mail/compare/v2.10.5...v2.10.6) (2026-04-21)
 
 

package/dist/server/index.js

@@ -15851,7 +15851,7 @@ var oauth$1 = ({ strapi: strapi2 }) => ({
     return account;
   }
 });
-const version = "2.10.5";
+const version = "2.10.6";
 const require$$2 = {
   version
 };
@@ -16277,8 +16277,11 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
     });
   },
   /**
-   * Get template by ID (documentId or numeric id) with populated versions
-   * Supports both documentId (string) and numeric id for backward compatibility
+   * Get template by ID (numeric id or documentId) with populated versions.
+   *
+   * Numeric IDs are interpreted as `templateReferenceId` first (this is the
+   * app-wide convention — see findById() below), then as legacy DB id.
+   * Non-numeric strings are treated as Strapi v5 `documentId`s.
    */
   async findOne(idOrDocumentId) {
     const isNumericId = /^\d+$/.test(String(idOrDocumentId));
@@ -16294,28 +16297,35 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
   /**
    * Get template by numeric ID.
    *
-   * HISTORICAL NOTE — this method supports two semantics for historical
-   * compatibility: the internal Strapi DB id AND the user-settable
-   * `templateReferenceId`. They are both `integer`, both `unique`, and
-   * they CAN collide (e.g. Template A has db.id=5 and Template B has
-   * templateReferenceId=5). Up until now the lookup tried
-   * templateReferenceId *first* and fell back to the DB id — which
-   * meant "Send Test" on the admin UI (which passes the DB id) would
-   * silently send the WRONG template if another template happened to
-   * have a templateReferenceId matching that number.
+   * CONTRACT — every HTTP route that carries `:id` (admin UI, REST callers,
+   * magic-link's `magic_mail_template_id`, Strapi's own test-send) refers to
+   * the user-visible `templateReferenceId`. That is what `TemplateList`
+   * navigates with, what `EditorPage` reads from `useParams()`, and what the
+   * `findAll()` response surfaces as `templateReferenceId` (alongside `.id`).
    *
-   * Correct ordering: ask the DB id first (that is the value every
-   * `findAll()` response carries as `.id`, and that is what the admin
-   * UI and Strapi's own routing use). Only if that truly misses, try
-   * the reference id as a best-effort fallback for legacy callers that
-   * already persisted a reference id as their template key.
+   * So: we resolve the reference id FIRST. The DB id is only kept as a
+   * best-effort fallback for very old installs that might have persisted
+   * the Strapi primary key as their template key before the reference id
+   * was introduced. Collisions between the two ID spaces are prevented on
+   * create() (refId uniqueness is enforced there).
    *
-   * When the fallback actually fires we log WARN + print both IDs so
-   * the operator can spot and fix a collision in their data.
+   * We intentionally do NOT spam warn-logs in the success path: the
+   * reference-id lookup IS the primary path.
    */
   async findById(id) {
     const numericId = Number(id);
-    strapi2.log.info(`[magic-mail] [LOOKUP] Finding template by numeric ID: ${numericId}`);
+    strapi2.log.info(`[magic-mail] [LOOKUP] Finding template by ID: ${numericId}`);
+    const byRefId = await strapi2.documents(EMAIL_TEMPLATE_UID).findMany({
+      filters: { templateReferenceId: numericId },
+      limit: 1,
+      populate: { versions: true }
+    });
+    if (byRefId.length > 0) {
+      strapi2.log.info(
+        `[magic-mail] [SUCCESS] Found template by templateReferenceId ${numericId}: documentId=${byRefId[0].documentId}, name="${byRefId[0].name}"`
+      );
+      return byRefId[0];
+    }
     let byInternalId = null;
     try {
       byInternalId = await strapi2.entityService.findOne(EMAIL_TEMPLATE_UID, numericId, {
@@ -16325,21 +16335,12 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
       strapi2.log.debug(`[magic-mail] [LOOKUP] entityService.findOne(${numericId}) threw: ${err.message}`);
     }
     if (byInternalId) {
-      strapi2.log.info(`[magic-mail] [SUCCESS] Found template by internal id ${numericId}: documentId=${byInternalId.documentId}, name="${byInternalId.name}"`);
-      return byInternalId;
-    }
-    const byRefId = await strapi2.documents(EMAIL_TEMPLATE_UID).findMany({
-      filters: { templateReferenceId: numericId },
-      limit: 1,
-      populate: { versions: true }
-    });
-    if (byRefId.length > 0) {
-      strapi2.log.warn(
-        `[magic-mail] [FALLBACK] No template with internal id=${numericId}; resolved via templateReferenceId=${numericId} → "${byRefId[0].name}" (documentId=${byRefId[0].documentId}). If the caller meant the DB id, this is the wrong record — update the caller to pass templateReferenceId explicitly or use findByReferenceId().`
+      strapi2.log.info(
+        `[magic-mail] [LEGACY-LOOKUP] No templateReferenceId=${numericId}; resolved via internal DB id=${numericId} → "${byInternalId.name}" (documentId=${byInternalId.documentId}). Consider storing the template's templateReferenceId (${byInternalId.templateReferenceId ?? "none set"}) instead of its DB id to keep callers stable across migrations.`
       );
-      return byRefId[0];
+      return byInternalId;
     }
-    strapi2.log.warn(`[magic-mail] [WARNING] Template with ID ${numericId} not found (tried internal id and templateReferenceId)`);
+    strapi2.log.warn(`[magic-mail] [WARNING] Template with ID ${numericId} not found (tried templateReferenceId and internal DB id)`);
     return null;
   },
   /**

package/dist/server/index.mjs

@@ -15838,7 +15838,7 @@ var oauth$1 = ({ strapi: strapi2 }) => ({
     return account;
   }
 });
-const version = "2.10.5";
+const version = "2.10.6";
 const require$$2 = {
   version
 };
@@ -16264,8 +16264,11 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
     });
   },
   /**
-   * Get template by ID (documentId or numeric id) with populated versions
-   * Supports both documentId (string) and numeric id for backward compatibility
+   * Get template by ID (numeric id or documentId) with populated versions.
+   *
+   * Numeric IDs are interpreted as `templateReferenceId` first (this is the
+   * app-wide convention — see findById() below), then as legacy DB id.
+   * Non-numeric strings are treated as Strapi v5 `documentId`s.
    */
   async findOne(idOrDocumentId) {
     const isNumericId = /^\d+$/.test(String(idOrDocumentId));
@@ -16281,28 +16284,35 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
   /**
    * Get template by numeric ID.
    *
-   * HISTORICAL NOTE — this method supports two semantics for historical
-   * compatibility: the internal Strapi DB id AND the user-settable
-   * `templateReferenceId`. They are both `integer`, both `unique`, and
-   * they CAN collide (e.g. Template A has db.id=5 and Template B has
-   * templateReferenceId=5). Up until now the lookup tried
-   * templateReferenceId *first* and fell back to the DB id — which
-   * meant "Send Test" on the admin UI (which passes the DB id) would
-   * silently send the WRONG template if another template happened to
-   * have a templateReferenceId matching that number.
+   * CONTRACT — every HTTP route that carries `:id` (admin UI, REST callers,
+   * magic-link's `magic_mail_template_id`, Strapi's own test-send) refers to
+   * the user-visible `templateReferenceId`. That is what `TemplateList`
+   * navigates with, what `EditorPage` reads from `useParams()`, and what the
+   * `findAll()` response surfaces as `templateReferenceId` (alongside `.id`).
    *
-   * Correct ordering: ask the DB id first (that is the value every
-   * `findAll()` response carries as `.id`, and that is what the admin
-   * UI and Strapi's own routing use). Only if that truly misses, try
-   * the reference id as a best-effort fallback for legacy callers that
-   * already persisted a reference id as their template key.
+   * So: we resolve the reference id FIRST. The DB id is only kept as a
+   * best-effort fallback for very old installs that might have persisted
+   * the Strapi primary key as their template key before the reference id
+   * was introduced. Collisions between the two ID spaces are prevented on
+   * create() (refId uniqueness is enforced there).
    *
-   * When the fallback actually fires we log WARN + print both IDs so
-   * the operator can spot and fix a collision in their data.
+   * We intentionally do NOT spam warn-logs in the success path: the
+   * reference-id lookup IS the primary path.
    */
   async findById(id) {
     const numericId = Number(id);
-    strapi2.log.info(`[magic-mail] [LOOKUP] Finding template by numeric ID: ${numericId}`);
+    strapi2.log.info(`[magic-mail] [LOOKUP] Finding template by ID: ${numericId}`);
+    const byRefId = await strapi2.documents(EMAIL_TEMPLATE_UID).findMany({
+      filters: { templateReferenceId: numericId },
+      limit: 1,
+      populate: { versions: true }
+    });
+    if (byRefId.length > 0) {
+      strapi2.log.info(
+        `[magic-mail] [SUCCESS] Found template by templateReferenceId ${numericId}: documentId=${byRefId[0].documentId}, name="${byRefId[0].name}"`
+      );
+      return byRefId[0];
+    }
     let byInternalId = null;
     try {
       byInternalId = await strapi2.entityService.findOne(EMAIL_TEMPLATE_UID, numericId, {
@@ -16312,21 +16322,12 @@ var emailDesigner$1 = ({ strapi: strapi2 }) => ({
       strapi2.log.debug(`[magic-mail] [LOOKUP] entityService.findOne(${numericId}) threw: ${err.message}`);
     }
     if (byInternalId) {
-      strapi2.log.info(`[magic-mail] [SUCCESS] Found template by internal id ${numericId}: documentId=${byInternalId.documentId}, name="${byInternalId.name}"`);
-      return byInternalId;
-    }
-    const byRefId = await strapi2.documents(EMAIL_TEMPLATE_UID).findMany({
-      filters: { templateReferenceId: numericId },
-      limit: 1,
-      populate: { versions: true }
-    });
-    if (byRefId.length > 0) {
-      strapi2.log.warn(
-        `[magic-mail] [FALLBACK] No template with internal id=${numericId}; resolved via templateReferenceId=${numericId} → "${byRefId[0].name}" (documentId=${byRefId[0].documentId}). If the caller meant the DB id, this is the wrong record — update the caller to pass templateReferenceId explicitly or use findByReferenceId().`
+      strapi2.log.info(
+        `[magic-mail] [LEGACY-LOOKUP] No templateReferenceId=${numericId}; resolved via internal DB id=${numericId} → "${byInternalId.name}" (documentId=${byInternalId.documentId}). Consider storing the template's templateReferenceId (${byInternalId.templateReferenceId ?? "none set"}) instead of its DB id to keep callers stable across migrations.`
       );
-      return byRefId[0];
+      return byInternalId;
     }
-    strapi2.log.warn(`[magic-mail] [WARNING] Template with ID ${numericId} not found (tried internal id and templateReferenceId)`);
+    strapi2.log.warn(`[magic-mail] [WARNING] Template with ID ${numericId} not found (tried templateReferenceId and internal DB id)`);
     return null;
   },
   /**

package/package.json

@@ -1,5 +1,5 @@
 {
-  "version": "2.10.6",
+  "version": "2.10.7",
   "keywords": [
     "strapi",
     "plugin",