feat: Make data wizard update objects

[monsieurswag]

The update doesn't concern the following objects:

• ComplianceAssessment
• RiskAssessment
• FindingAssessment

These objects are created with the f"{object_type}_{timestamp}" format which is meant to be a unique name generated by the backend (not user-provided and therefore not updatable)

[coderabbitai]

Walkthrough

Single-file refactor of backend/data_wizard/views.py that adjusts the public API surface by updating model imports and restructures multiple _process_* methods to locate existing instances by name/reference before passing them to serializers, changing serialization flow and record creation behavior.

Changes

Cohort / File(s)

Change Summary

Data Wizard Views Refactor backend/data_wizard/views.py

Import augmentation: added ElementaryAction from ebios_rm.models; refined core.models imports (removed Framework, RiskAssessment, RiskScenario, ReferenceControl, Threat; added Asset); narrowed tprm.models imports (kept only Entity, removed Solution, Contract). Refactored _process_users, _process_assets, _process_applied_controls, _process_perimeters, _process_elementary_actions methods to locate existing instances by name/reference before serializer passage, changing serialization flow and record update behavior. Enhanced error handling with pre-validation lookups and try/except integration; improved logging around creation/linking steps.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Refactoring pattern across five _process_* methods from direct instance creation to existing instance lookup—requires verifying all edge cases and error paths are correctly handled
• Serialization flow changes impact record creation/update behavior—careful review needed to ensure data consistency and correct update semantics
• Public API surface changes (import removals/additions)—verify no downstream dependencies are broken
• Error handling integration—ensure exception propagation and logging are consistent across all refactored methods

Poem

🐰 From new to found, we've changed our way,
Instances now dance where lookups play,
A cleaner path through Asset's gate,
Less creation, more to validate! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: enabling the data wizard to update existing objects rather than just creating new ones.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/update_object_with_data_wizard

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

backend/data_wizard/views.py (2)

523-613: Consider extending upsert behavior to remaining _process_* methods for consistency.

The upsert pattern (lookup existing instance before serialization) has been implemented for Users, Assets, AppliedControls, Perimeters, and ElementaryActions. However, _process_reference_controls, _process_threats, _process_folders, _process_processings, and TPRM-related methods still use create-only behavior.

If the intent is to support full upsert semantics across the data wizard, consider applying the same pattern to these methods in a follow-up. If this is intentional (e.g., these entities should always create new records), documenting this distinction would help future maintainers.

---

265-265: Consider updating log messages to reflect upsert behavior.

Log messages like "Error creating asset" don't reflect that the operation might be an update. Consider using "Error saving asset" or "Error creating/updating asset" for accuracy.

This applies to similar log messages in _process_applied_controls (line 331), _process_perimeters (line 387), _process_elementary_actions (line 513), and _process_users (line 212).

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8f1a9ac and 7b714e0.

📒 Files selected for processing (1)

• backend/data_wizard/views.py (13 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)

• GitHub Check: startup-docker-compose-test
• GitHub Check: enterprise-startup-functional-test (3.12)
• GitHub Check: startup-functional-test (3.12)
• GitHub Check: enterprise-startup-docker-compose-test
• GitHub Check: build_enterprise_frontend
• GitHub Check: build_community_frontend
• GitHub Check: build (3.12)
• GitHub Check: test (3.12)
• GitHub Check: Analyze (python)

🔇 Additional comments (6)

backend/data_wizard/views.py (6)

8-9: Import changes look correct.

The added imports (ElementaryAction, Asset) are required for the new instance lookup functionality in the upsert flow. Narrowing tprm.models to only Entity is appropriate since Solution and Contract are only accessed via their serializers.

Also applies to: 18-18, 36-36

---

179-218: Upsert pattern for users looks correct.

The implementation properly:

1. Validates the mandatory email field before lookup
2. Uses email as the unique identifier to find existing users
3. Passes the found instance (or None) to the serializer for create/update behavior

---

246-253: Asset upsert with composite key (name, folder) is appropriate.

The lookup correctly uses both name and folder to identify existing assets, which prevents unintended cross-folder updates. Django's ORM accepts folder IDs directly for ForeignKey lookups.

---

310-319: Applied control upsert follows the same consistent pattern.

Uses the same composite key approach (name, folder) as assets, maintaining consistency across entity types.

---

368-375: Perimeter upsert maintains consistency with other entities.

Follows the established composite key pattern (name, folder) for instance lookup.

---

492-501: Elementary action upsert completes the consistent pattern across all entity types.

The implementation properly uses the newly imported ElementaryAction model for instance lookups, maintaining the same composite key approach.