fix(identity): make Key Info reachable everywhere and keep key labels/holdings consistent (#889)

CHANGELOG.md

@@ -94,6 +94,41 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
+- **An identity's keys are reachable again**: the keys list under an identity's
+  Settings → Advanced now opens each key's own page, so keys can be inspected
+  and restored — and, once a key is on this device, signed with or
+  password-protected — without changing the interface mode and without starting
+  a payment. Previously that list was a read-only table with no way onward, and
+  every route to a key's page ran through an action screen — sending,
+  withdrawing, a token operation — each of which offers it only when the
+  identity already holds a key of the kind that action needs. So an identity
+  missing its keys, the one case where this matters most, could not get to them
+  at all. The offer to restore keys left behind by an earlier version now also
+  appears on the keys list itself, above the keys, rather than only inside a
+  key's page. Each key is named by its role and states whether it is saved on
+  this device. Keys are named for the identity they belong to: a user identity's
+  keys are described in plain language rather than in masternode registration
+  terms, which previously appeared on every identity. Leaving a key returns to
+  the list with both its keys and the restore offer brought up to date, so a
+  restore made from a key's page is reflected immediately instead of being
+  offered again.
+
+  A key opened from a masternode's page keeps its name too. A voting key is the
+  node's voting key however it is recorded, and its own page now says so instead
+  of describing it as another kind of key, which also means the page no longer
+  reports such a key as missing while the list it was opened from shows it as
+  saved on this device.
+
+  One known limitation, for a voting key stored on the identity itself rather
+  than on a separate voting identity: the keys list and the key's page now agree
+  on whether such a key is saved here, but saving or removing one by hand can
+  affect a voting key of the same number on a linked voting identity, and
+  removing it may leave the original in place. So until then, after saving or
+  removing a voting key on an identity like that, open the keys list and check
+  that each key still reads as you expect, and re-enter any key that should be
+  saved but no longer is. This will be closed by the in-progress key-placement
+  resolution fix.
+
 - **Wallet rename consistency**: renaming a wallet no longer overwrites other
   saved wallet details when metadata cannot be read. Overlapping renames and
   wallet removals also keep displayed aliases and deleted-wallet metadata

docs/ai-design/2026-07-28-legacy-identity-recovery/design.md

@@ -792,3 +792,33 @@ the eager vault migration inside the read path — a caller already holding the
 guard reaches it, so taking it there would self-deadlock. That write is
 idempotent (it replaces plaintext with vault placeholders in the blob it just
 read) and carries a TODO to fold it into the guarded path.
+
+### 10.14 The Key Info offer needed a route before it was reachable at all
+
+§2.1 named the Key Info screen as reachable "from the Identities screen for
+`User` identities and via 'Manage keys' for nodes", and §7 row 1 called the
+entry point discoverable. Both were false for `User` identities as shipped.
+
+The legacy `IdentitiesScreen` per-key popup is the route §2.1 means, and
+`ui/components/left_panel.rs` deliberately drops `RootScreenIdentities` from the
+nav, so nothing navigates to it. The identity hub's replacement surface —
+Settings → Advanced → "Manage keys" — opened a read-only key table with no way
+into `KeyInfoScreen`. Every remaining route (transfer, withdraw, the token
+screens) is gated on the identity already holding a key of the kind that action
+needs, which is exactly false for the identities this flow exists to help. A
+`User` identity with stranded keys could therefore reach the offer only in
+Developer view, through a send-money screen.
+
+§2.1 and §7 row 1 are both left as written, per this document's model — the
+proposal stands as proposed and this section is the correction. A third surface
+now carries the offer that §2.1 names two for, and the mechanism §7 row 1 calls
+an "on-arrival" detection task is the `ensure_checked()` render-loop latch of
+§10.1.
+
+Shipped: `KeysScreen` carries the `QualifiedIdentity`, renders one row per key
+in the §10.8 vocabulary with its held state in words, and opens
+`KeyInfoScreen` for any key regardless of what the device holds. The offer
+itself renders on that list, above the rows, because it is identity-scoped —
+requiring a user to pick an arbitrary key to discover an identity-level offer
+repeats the defect one level up. The offer stays on `KeyInfoScreen` too: it
+self-extinguishes, and the masternode path lands there.

docs/user-stories.md

@@ -670,8 +670,12 @@ As a user, I want the identities I loaded before an upgrade — and the keys the
 
 As a user whose identity was already in the app before the upgrade — a masternode loaded from its ProTxHash, or an identity holding only some of its keys — I want to bring across the keys that stayed behind in the previous version's data, so that I do not have to re-enter private keys I no longer have on hand.
 
-- The offer appears on the identity's own page — the node detail page and the Key Info screen — only when the previous version's data actually holds keys this identity does not, and it disappears once there is nothing left to restore.
-- The list names each key by its role and is exactly what gets restored. Nothing is restored without pressing Restore, and nothing happens automatically at launch or during the upgrade.
+- The offer appears on the identity's own page — the node detail page, the identity's keys list, and the Key Info screen — only when the previous version's data actually holds keys this identity does not, and it disappears once there is nothing left to restore.
+- The keys list is reachable without changing the interface mode and without starting a payment: an identity's keys are listed under Settings, and every key opens its own page whether or not this device holds that key. Keys that are missing are exactly the ones a user comes here about, so a key the device does not hold is never hidden or unopenable.
+- The offer sits above the key list, so a user whose keys are missing finds it without opening a key first.
+- Each key is named by its role and says whether it is saved on this device, in words rather than by colour alone. The role words match the identity: a user identity's keys are named in plain language, not in masternode registration terms, and the restore offer above the list uses the same words as the list itself.
+- Leaving a key returns to the keys list with both the keys and the restore offer up to date, so a restore made from a key's page is never offered a second time.
+- The restore offer lists each key by its role, and that list is exactly what gets restored. Nothing is restored without pressing Restore, and nothing happens automatically at launch or during the upgrade.
 - Keys already saved for the identity are never replaced or removed — only missing ones are added. An identity the user deleted is never brought back.
 - On a password-protected identity the identity password is asked for first; cancelling, or getting it wrong, leaves everything exactly as it was.
 - An owner or payout key that is genuinely missing comes back this way. A voting key held on a separate voting identity does not, unless the identity's own record already links to that voting identity: otherwise nothing but the previous version's data says the node still uses that key, so it is listed as one that cannot be brought back and entering it by hand stays the remedy. Checking such a key against the chain, which would let it be restored safely, is tracked as issue #942.

src/ui/components/legacy_recovery_section.rs

@@ -14,7 +14,7 @@ use crate::model::legacy_recovery::{
     ExclusionReason, RecoveryItem, RecoveryItemDescriptor, RecoveryPlan,
 };
 use crate::ui::components::component_trait::{Component, ComponentResponse};
-use crate::ui::masternodes::{disambiguate_role_labels, role_label_and_tip};
+use crate::ui::masternodes::{KeyVocabulary, disambiguate_role_labels, role_label_and_tip};
 use crate::ui::theme::DashColors;
 
 /// Section lead-in. Avoids "migration", "blob" and "vault" — the user knows
@@ -95,13 +95,15 @@ pub fn exclusion_explanation(reason: ExclusionReason) -> &'static str {
 /// item is named here exactly as the "Manage keys" list names the same key, and
 /// two rows that would otherwise read alike are told apart by their key id.
 pub fn recovery_item_labels(
+    vocabulary: KeyVocabulary,
     items: &[&RecoveryItemDescriptor],
 ) -> Vec<(String, Option<&'static str>)> {
     let mut labels: Vec<(String, Option<&'static str>)> = items
         .iter()
         .map(|item| match &item.item {
             RecoveryItem::Key { .. } => {
                 let (role, tip) = role_label_and_tip(
+                    vocabulary,
                     item.is_on_voter_identity(),
                     item.purpose.unwrap_or(Purpose::AUTHENTICATION),
                 );
@@ -155,14 +157,23 @@ impl ComponentResponse for LegacyRecoverySectionResponse {
 pub struct LegacyRecoverySection<'a> {
     plan: &'a RecoveryPlan,
     restoring: bool,
+    vocabulary: KeyVocabulary,
 }
 
 impl<'a> LegacyRecoverySection<'a> {
-    /// The offer for `plan`.
-    pub fn new(plan: &'a RecoveryPlan) -> Self {
+    /// The offer for `plan`, naming its keys in `vocabulary`.
+    ///
+    /// `vocabulary` is an argument rather than a builder option on purpose. This
+    /// offer is hosted by three separate screens, and a default would let a
+    /// fourth inherit the wrong wording silently: naming a user identity's
+    /// transfer key a "payout address key" asserts it owns a masternode, and
+    /// disagrees with the keys list rendered right below the offer. Required
+    /// here, every host has to answer for the identity it is showing.
+    pub fn new(plan: &'a RecoveryPlan, vocabulary: KeyVocabulary) -> Self {
         Self {
             plan,
             restoring: false,
+            vocabulary,
         }
     }
 
@@ -196,7 +207,7 @@ impl Component for LegacyRecoverySection<'_> {
                 ui.label(RichText::new(intro).color(DashColors::warning_color(dark_mode)));
 
                 let previewed = self.plan.preview_items();
-                for (label, tip) in recovery_item_labels(&previewed) {
+                for (label, tip) in recovery_item_labels(self.vocabulary, &previewed) {
                     ui.horizontal(|ui| {
                         ui.add_space(12.0);
                         let row = ui
@@ -238,8 +249,9 @@ impl Component for LegacyRecoverySection<'_> {
                     let excluded: Vec<&RecoveryItemDescriptor> =
                         self.plan.excluded.iter().map(|(item, _)| item).collect();
                     let reasons = self.plan.excluded.iter().map(|(_, reason)| *reason);
-                    for ((label, _), reason) in
-                        recovery_item_labels(&excluded).into_iter().zip(reasons)
+                    for ((label, _), reason) in recovery_item_labels(self.vocabulary, &excluded)
+                        .into_iter()
+                        .zip(reasons)
                     {
                         ui.horizontal(|ui| {
                             ui.add_space(12.0);