Add legacy device deprecation banner for users and admins

[mindmonk]

To inform users ahead of time, a warning banner is shown on the profile page and vault list whenever the logged-in user still has legacy devices.

Admins additionally see a variant of this banner on the vault list and admin settings page when any user in the system has legacy devices.

Screenshots:
User – Profile Page

User – Vault List

Admin – Vault List

Admin – Admin Settings

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 54cbf1a4-eea6-4f37-b007-32f9d98d44e7

📥 Commits

Reviewing files that changed from the base of the PR and between b90b4ee and dae54e0.

📒 Files selected for processing (4)

• CHANGELOG.md
• frontend/src/common/backend.ts
• frontend/src/components/VaultList.vue
• frontend/src/i18n/en-US.json

✅ Files skipped from review due to trivial changes (2)

• CHANGELOG.md
• frontend/src/i18n/en-US.json

---

Walkthrough

Adds a deprecated backend endpoint GET /devices/has-legacy-devices (DeviceResource.hasAnyLegacyDevices) that returns a boolean by delegating to LegacyDevice.Repository.existsAny(), which checks for the presence of any LegacyDevice record. Frontend: DeviceService.hasLegacyDevices() calls that endpoint. AdminSettings, LegacyDeviceList, and VaultList components fetch legacy-device state and conditionally render a ContentBanner. Three i18n keys for the banner title and user/admin descriptions were added. CHANGELOG updated with an "Added" entry about displaying the legacy-device banner.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Show legacy devices in user profile and legacy device name in audit log #331 — Related changes to DeviceResource and legacy-device handling (adds/extends legacy-device endpoints and repository methods)

Suggested reviewers

• overheadhunter

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding legacy device deprecation banners for both users and admins across multiple pages.
Description check	✅ Passed	The description clearly explains the feature, specifying where banners appear for users and admins, and includes relevant screenshots demonstrating the implementation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/legacy-device-banner

---

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]

🧹 Nitpick comments (1)

frontend/src/components/VaultList.vue (1)

219-220: Optional chaining on non-optional field.

The devices field on UserDto is typed as DeviceDto[] (non-optional). The optional chaining meWithLegacy.devices?.length is defensive but technically unnecessary. This is a minor nitpick and safe to keep as-is.

📝 Optional simplification

-    hasLegacyDevices.value = (meWithLegacy.devices?.length ?? 0) > 0;
+    hasLegacyDevices.value = meWithLegacy.devices.length > 0;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/components/VaultList.vue` around lines 219 - 220, The optional
chaining on a non-optional field is unnecessary; in the block that awaits
userdata.meWithLegacyDevicesAndLastAccess, replace the defensive access
meWithLegacy.devices?.length with a direct access meWithLegacy.devices.length
(keeping the surrounding assignment to hasLegacyDevices.value) so the code uses
the declared DeviceDto[] type correctly; update the expression where
meWithLegacy and hasLegacyDevices are referenced to remove the "?".

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@frontend/src/components/VaultList.vue`:
- Around line 219-220: The optional chaining on a non-optional field is
unnecessary; in the block that awaits userdata.meWithLegacyDevicesAndLastAccess,
replace the defensive access meWithLegacy.devices?.length with a direct access
meWithLegacy.devices.length (keeping the surrounding assignment to
hasLegacyDevices.value) so the code uses the declared DeviceDto[] type
correctly; update the expression where meWithLegacy and hasLegacyDevices are
referenced to remove the "?".

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 10fdecee-193f-4700-8683-2e922ec07cc0

📥 Commits

Reviewing files that changed from the base of the PR and between 5614653 and 8bba159.

📒 Files selected for processing (7)

• backend/src/main/java/org/cryptomator/hub/api/DeviceResource.java
• backend/src/main/java/org/cryptomator/hub/entities/LegacyDevice.java
• frontend/src/common/backend.ts
• frontend/src/components/AdminSettings.vue
• frontend/src/components/LegacyDeviceList.vue
• frontend/src/components/VaultList.vue
• frontend/src/i18n/en-US.json

[overheadhunter]

I have slight concerns regarding fetch efficiency of userdata.meWithLegacyDevicesAndLastAccess but since this is just a temporary banner, this should work.

@SailReal do you agree?

[SailReal]

We should remove the banner soon again but then I think it is okay to use meWithLegacyDevicesAndLastAccess.