chore: use setDeep for v3 to v4

[minottic]

Description

Create helper function and pipe to transform the body from v3 to v4 based on function/key mapping

Motivation

Reduces code duplication

[Junjiequan]

I'm not sure if the refactor is necessary. The util function seems to be used only for the publishedData. The convertObsoleteToCurrentSchema is long indeed, but it is explicit and easy to read

[nitrosx]

I asked AI to provide a summary of the changes and evaluate if the changes are necessary, and I got the following report:

Assessment

Aspect	Rating	Notes
Necessity	✅ Yes	Reduces 137 lines of manual mapping to ~30 lines of reusable utilities
DRY	✅ Good	Eliminates duplicated mapping logic
Type Safety	⚠️ Partial	Still uses type assertions (as unknown as...) in controller
Maintainability	✅ Improved	Single source of truth for field mappings

---

Improvements Needed

• Eliminate type assertions:
  The controller still has as unknown as CreatePublishedDataV4Dto casts. The pipe should return properly typed DTOs.

• Pipe reusability:
  V3ToV4MigrationPipe is generic but only used for v3→v4. Consider making the field map configurable via constructor.

• Error handling:
  setDeep silently skips undefined values. Consider logging or throwing for missing required fields.

• Documentation:
  Add JSDoc for setDeep and createDeepSetter explaining the [] array syntax.

• Test coverage:
  Add tests for setDeep and createDeepSetter to match the removed controller tests.

• Unused code:
  The commit "Remove redundant function" suggests there was dead code—verify all original functionality is preserved.

---

Verdict

• Necessary: Yes. The refactoring reduces code duplication and centralizes mapping logic.
• Production ready: Almost. Needs type safety improvements and test coverage for the new utilities before merging.

[minottic]

sorry @Junjiequan, I missed your comment. Also, thanks @nitrosx for the review. My intention was that this function can be later applied inplace of all the custom mappings we have and it will reduce code duplication quite a bit. I will tackle the suggestions soon

[nitrosx]

I also used a different prompt to validate the previous finding:

Verdict

Criteria	Status
Logic Correctness	✅ Pass
Edge Cases	✅ Adequate
Architecture	✅ Improved
Unreachable Code	✅ None
Production Ready	✅ Yes

Summary: The refactoring successfully replaces manual mapping with a generic, reusable solution while maintaining all functionality. The changes are clean, focused, and follow NestJS best practices.

[nitrosx]

Security Review: Branch set_deep Changes

Summary Table

Category	Status	Details
Injection Vulnerabilities	✅ No	Uses lodash get/set/merge/trim safely (v4.17.21). No eval, SQL, or command execution. Paths are hardcoded in field maps, not user-controlled.
Sensitive Data Exposure	✅ No	Only transforms existing DTO fields. No new PII exposed. Same data was already in v3 API.
Insecure API Usage	✅ No	No new HTTP calls. OAIServerUri from config. No hardcoded credentials or API keys.
Authentication Bypass	✅ No	All modified endpoints retain @UseGuards(PoliciesGuard) and @CheckPolicies. Pipe is only a transformation layer.

---

Detailed Findings

1. Pipe Security (body-dto.pipe.ts)

• Stateless transformation only
• No access to request context, headers, or auth tokens
• Cannot modify authentication state

2. lodash Usage (deep-mapper.util.ts)

• Version 4.17.21 (patched against prototype pollution)
• Safe functions: get, set, merge, trim
• Field paths are hardcoded in publishedDataV3toV4FieldMap, not user input

3. Controller Changes

• All endpoints (POST /, PATCH /:id, POST /:id/resync) maintain existing guards
• No auth logic was removed or modified
• Type assertions (as unknown as) are TypeScript-only, no runtime impact

4. Data Flow

• Input: v3 DTO → Pipe transforms to v4 DTO → Service layer
• Output: v4 entity → Serialized to v3 DTO
• No data leaves its intended scope

---

Conclusion

No security vulnerabilities introduced. The changes are safe and maintain all existing security controls. The refactoring improves code maintainability by moving transformation logic into a dedicated pipe without compromising security.

[nitrosx]

@minottic thank you for your patience. I am testing few new ways to review PRs using AI, and I thought that this small one was a good test

[minottic]

@minottic thank you for your patience. I am testing few new ways to review PRs using AI, and I thought that this small one was a good test

this might also be another good test case :)