fix: always create content type on test migration, disable Save when …

[yashin4112]

🔗 Jira Ticket

. CMG-995
· CMG-1048

---

📋 PR Type

• ✨ Feature
• 🐛 Bug Fix
• 🔥 Hotfix
• ♻️ Refactor
• 🧹 Chore / Dependency Update
• 📝 Documentation

---

📝 Description

What changed?

• fieldAttacher (api): Added an isTest flag. On test migrations the content type is now always (re)created into the test stack, short-circuiting the iteration-based skip logic. Previously the isTest block and the iteration block both ran on the same pass, causing each content type to be created twice.
• EntryMapper (ui): Save button is now disabled when the selected content type has no mappable entry (no row has a Contentstack UID), on top of the existing in-flight-migration lock.

Why?

• Test migrations must reflect the latest content type schema regardless of whether it already exists — the previous fall-through created content types twice and applied the wrong iteration/skip logic.
• Nothing is savable when a content type has no entry mapped to a Contentstack UID, so the Save action was misleading.

---

🧩 Affected Areas

• api — Node.js backend
• ui — React frontend
• upload-api — Upload API server
• docker / docker-compose
• CI / GitHub Actions workflows
• Environment variables / config
• Other:

---

🧪 How to Test

1. Run a test migration and confirm each content type is created into the test stack exactly once (no double-create), including content types that already exist from a previous iteration.
2. Run a real migration and confirm iteration-based skip logic still applies (existing content types are skipped on iteration 2+).
3. In the Entry Mapper step, open a content type whose entries all show - for Contentstack UID → Save should be disabled.
4. Open a content type with at least one mapped Contentstack UID → Save should be enabled.

Expected result: Test migrations create content types once; Save is only enabled when there's something mappable to save.

---

📸 Screenshots / Recordings

Before	After

---

🔗 Related PRs / Dependencies

---

✅ Author Checklist

• Branch follows naming convention: feature/, bugfix/, or hotfix/ + 5–30 lowercase chars
• Jira ticket linked above
• Self-reviewed the diff — no debug logs, commented-out code, or TODOs left in
• .env / example.env updated if new environment variables were added — N/A
• No sensitive credentials or secrets committed
• Existing tests pass locally (npm test)
• New tests written (or not applicable — explain why)
• README.md / docs updated if behaviour changed
• Talisman pre-push scan passes (no secrets flagged)

---

👀 Reviewer Notes

Focus on the branching in fieldAttacher — the fix converts the old separate if (isTest) + if (iteration === 1) blocks into a single if / else if / else so test migrations no longer fall through into the iteration logic.

---

Migration v2 · Docs · Issues

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	7	384	25	✅ Passed
🟡 Medium Severity	10	11	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 384
• Medium without fixes: 11
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed

[umesh-more-cstk]

Review: fix test-migration content-type creation + Save-button lock

Non-gating COMMENT review. Two independent fixes; both are on the right track and well scoped (touches only api + ui, matching the Affected Areas — no lockfile/cross-package churn). I traced the field-attacher call sites, the entry-mapper pagination flow, and the content-type write path at the head commit.

Verified good

• field-attacher.utils.ts — the if (isTest) / else if (iteration === 1) / else restructuring is correct and mutually exclusive; no double-create. The real (final) migration at migration.service.ts:885 correctly omits isTest, so it defaults to false and the iteration/skip logic is preserved. The isTest: true wiring at migration.service.ts:453 (test flow) is right.
• _canSelect = !!entry.contentstackEntryUid semantics are consistent with the checkbox rowSelectCheckboxProp and the Save intent.

Blocking

• entryMapper.tsx:698 — the new Save-disable predicate inspects only the current page (tableData), which for this step is a single server-paginated slice. It can disable Save when the content type does have mappable entries (they're on another page) or when the user has unsaved selections made on a previous page. Details + fix inline.

Non-blocking

• field-attacher.utils.ts:50-51 (question) — always-create on test migrations interacts with the append-based saveContent (schemaData.push) and clearStaleEntries (scoped to entries/ only, so content_types/schema.json is never cleared). Please confirm the test stack / its content_types dir is fresh per run so repeated/delta test migrations don't accumulate duplicate content-type schema entries.
• field-attacher.utils.ts:53 (nit) — the isTest and iteration === 1 branches call contenTypeMaker with byte-identical args; could collapse to one condition.

Out-of-diff note (PR description)

The description's rationale — "Previously the isTest block and the iteration block both ran on the same pass, causing each content type to be created twice" — doesn't match the diff base: the pre-change code had only if (iteration === 1), no isTest block, so there was no double-create on dev. The actual prior bug this fixes is that delta (iteration 2+) test migrations skipped content-type creation into the fresh test stack. The resulting code is correct; just worth aligning the description so reviewers test the right scenario.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	7	384	25	✅ Passed
🟡 Medium Severity	10	11	500	✅ Passed
🔵 Low Severity	1	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 384
• Medium without fixes: 11
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed