fix: handle restore warning responses in upload UI

[lil-aditya]

Linked issue

• Closes [Bug] Legacy model restore warnings are ignored by the upload UI #420
• Related Move demo data archive to GitHub release asset, download on demand #293, Replace zf.extractall with safe_extractall #322, fix(backupCase): replace download thread race with after_this_request #229 #341, Fix: calculate relative arcname for backupCase ZIP generation (fixes #403) #404, fix(api): implement robust zip extraction and path sanitization #419

Existing related work reviewed

• Issues/PRs reviewed:
  • Move demo data archive to GitHub release asset, download on demand #293 Move demo data archive to GitHub release asset, download on demand
  • Replace zf.extractall with safe_extractall #322 Replace zf.extractall with safe_extractall
  • fix(backupCase): replace download thread race with after_this_request #229 #341 fix(backupCase): replace download thread race with after_this_request
  • Fix: calculate relative arcname for backupCase ZIP generation (fixes #403) #404 Fix: calculate relative arcname for backupCase ZIP generation
  • fix(api): implement robust zip extraction and path sanitization #419 fix(api): implement robust zip extraction and path sanitization
• None of the above appears to address the frontend restore-warning handling gap in the upload success callback.

Overlap assessment

• Classification: Adjacent but non-overlapping
• Overlapping items:
  • Move demo data archive to GitHub release asset, download on demand #293, Replace zf.extractall with safe_extractall #322, fix(backupCase): replace download thread race with after_this_request #229 #341, Fix: calculate relative arcname for backupCase ZIP generation (fixes #403) #404, and fix(api): implement robust zip extraction and path sanitization #419 are all archive / restore / ZIP-related at the backend or archive-processing layer
• Why this is not duplicate/superseded:
  • This PR fixes a frontend behavior bug in WebAPP/Classes/Base.Class.js
  • The backend already returns a valid legacy-restore warning response
  • The bug is that the browser success handler ignores that warning path entirely
  • As a result, a legacy restore can succeed on disk while the UI does not append the restored model, does not close the modal, and does not surface the upgrade warning
  • That is a separate issue from ZIP extraction safety, backup archive contents, or backend restore mechanics

Why this PR should proceed

• It fixes a real user-visible bug where successful legacy restores appear to fail in the UI
• The change is narrow, low-risk, and isolated to the upload success handler
• It improves correctness without changing backend contracts or adding broad refactors
• It restores expected behavior for legacy model uploads while preserving warning-only handling for non-restoring cases such as "already exists"

Summary

• What changed:
  • Added a small shared success helper for case-restore responses in WebAPP/Classes/Base.Class.js
  • Updated the upload success callback to handle three cases explicitly:
    • success
    • warning with message_warning for successful legacy restores
    • warning without restore side effects, such as "already exists"
  • Added a defensive guard for malformed / unexpected upload responses
• Why:
  • The backend intentionally returns status_code: "warning" for older model restores
  • The previous frontend code had an empty warning branch, so restore completion was not reflected in the UI
  • Users could therefore restore a legacy model successfully but see no appended model, no modal close, and no migration guidance

Validation

• Tests added/updated (or not applicable)
• Validation steps documented

Validation details:

• Ran a targeted Node-based harness against the actual upload success callback logic
• Verified expected behavior for:
  • success: model appended, success message shown, modal closed
  • legacy restore warning: model appended, success message shown, upgrade warning shown, modal closed
  • non-restoring warning: warning shown only, no UI mutation
  • error: danger message shown

Example validation output:

success: [["append","Demo"],["success","Upload response","ok",null],["modal","toggle"]]
warning_restore: [["append","Legacy"],["success","Upload response","uploaded",null],["warningOsy","needs update"],["modal","toggle"]]
warning_exists: [["warning","Upload response","already exists",null]]
error: [["danger","Upload response","bad zip",null]]

[Copilot]

Pull request overview

Fixes the restore/upload UI so that backend “legacy restore” responses returned as status_code: "warning" are treated as successful restores (append model, close modal) while still surfacing the warning guidance to the user.

Changes:

• Added a shared helper (handleCaseRestoreSuccess) to centralize “restore succeeded” UI actions.
• Updated the Dropzone upload success handler to distinguish:
  • success
  • warning with message_warning (legacy restore success + upgrade warning)
  • warning without restore side effects (warning-only)
• Added a guard for missing/empty response.response[0] payloads.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The success callback has no fallback for unexpected/malformed status_code values (or a missing status_code). In that case the handler will silently do nothing, which undermines the new defensive handling. Consider adding a final else that shows a danger/warning message (and optionally logs the payload) so users aren’t left with no UI feedback when the response shape changes.

Suggested change

	Message.bigBoxDanger("Upload response", result['message'], null);
	Message.bigBoxDanger("Upload response", result['message'], null);
	} else {
	console.warn('Unexpected upload response status_code', result);
	Message.bigBoxWarning("Upload response", "Upload completed but returned an unexpected status.", null);

[lil-aditya]

@SeaCelo @autibet please review this.