feat(assets): add extractAssets function for asset mapping across Con…

[yashin4112]

🔗 Jira Ticket

MIGRATION-1030

---

📋 PR Type

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

---

📝 Description

What changed?

• Added an extractAssets lib to the Contentful, WordPress, and Drupal connectors so each builds an assetMapping array in the upload-api and sends it in the createDummyData payload — the same flow AEM and Sitecore already use.
• Contentful (migration-contentful/libs/extractAssets.js): reads the export JSON's assets, dedupes by sys.id, pulls locale-keyed fields.file/fields.title.
• WordPress (migration-wordpress/libs/extractAssets.ts): walks WXR items, filters wp:post_type === 'attachment', dedupes by post id.
• Drupal (migration-drupal/libs/extractAssets.js): queries the file_managed table over MySQL, dedupes by fid.
• Each connector's uid matches the uid its api-side createAssets assigns, so delta dedupe / uid-mapper lookups line up across iterations.
• Wired extractAssets into each connector's mapper service/controller and exported it from each migration-* package index.
• Updated the WordPress controller unit test to mock the new extractAssets export.

Why?

Contentful, WordPress, and Drupal migrations never populated the AssetMapper UI because no assetMapping array was built on the upload side (only AEM and Sitecore did). This brings those three connectors to parity so their media assets appear on the Asset Mapper and participate in delta tracking.

---

🧩 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 migration for a Contentful export that has assets → open the mapper → Assets tab → assets appear (name/path/size/CS UID).
2. Repeat for a WordPress export (WXR with media attachments).
3. Repeat for a Drupal source (MySQL with rows in file_managed).
4. Confirm asset UIDs stay stable across a second (delta) iteration — re-run and verify existing assets are matched, not duplicated.

Expected result: Contentful, WordPress, and Drupal assets show on the AssetMapper (previously empty), with stable UIDs across iterations.

---

📸 Screenshots / Recordings

Before	After
(Assets tab empty)	(assets listed)

---

🔗 Related PRs / Dependencies

• Follows the same pattern introduced for AEM and Sitecore asset mapping.

---

✅ 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
• No sensitive credentials or secrets committed
• Existing tests pass locally (npm test)
• New tests written (or not applicable — updated existing WordPress controller test; connector extractAssets covered via controller/service flow)
• README.md / docs updated if behaviour changed
• Talisman pre-push scan passes (no secrets flagged)

---

👀 Reviewer Notes

• UID derivation per connector must match the api-side createAssets (Contentful sys.id, WordPress post id, Drupal fid) — that's the key to delta matching; worth a sanity check.
• Drupal's extractAssets opens its own MySQL connection (via dbConnection(config)) and closes it in finally, mirroring extractLocale.
• file_size is empty at extract time for Contentful/WordPress (only known after download); Drupal has it from file_managed.filesize.
• Not committed: a local upload-api/src/config/index.json dev tweak (cmsType/localPath) — intentionally left out of this PR.

---

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	1	0	10	✅ Passed
🟠 High Severity	2	382	25	✅ Passed
🟡 Medium Severity	0	0	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: 382
• Medium without fixes: 0
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed