feat(ui): consistent y/Enter confirmation for destructive actions (R25)#108
Merged
Conversation
Communities and VTA-DID deletes already require a y/Enter confirmation, but
`d` in Relationship detail, `d` in Credential detail, and `d`/`c` in the Inbox
deleted or dismissed instantly. This applies the existing
`confirm_delete: Option<…>` arm pattern to those three unguarded panels so
every destructive action behaves the same way.
- State (content.rs): add `RelationshipsState.confirm_delete: Option<String>`
(remote_p_did), `CredentialsState.confirm_delete: Option<String>` (vrc_id),
and `InboxState.confirm: Option<InboxConfirm>` where `InboxConfirm` is
`Dismiss { task_id } | ClearAll` (covers both the single-dismiss and
clear-all destructive paths).
- Actions: new pure arming/cancel variants — `RelationshipAction::{ConfirmRemove,
CancelRemove}`, `CredentialAction::{ConfirmRemove, CancelRemove}`, and
`InboxAction::{ConfirmDismiss, ConfirmClearAll, CancelConfirm}`. Handled as
pure state mutations in the respective `*_actions.rs` dispatchers (never
network); the commit handlers (`prepare_remove`, `handle_remove`,
`handle_dismiss_task`, `handle_clear_all`) clear the flag as the existing
community/VTA-DID commits do.
- Key handlers (main/mod.rs): the destructive keys now arm the confirmation;
while one is pending, y/Enter commits and any other key cancels (Esc
included), mirroring `handle_communities_key`/`handle_vta_key`.
- Render: each panel footer shows the "… ? y: confirm n: cancel" prompt
(orange/bold) while a confirmation is pending, matching the Communities panel.
The confirm fields live on the panel state and survive `sync_from_config`
(which updates the inner data vectors, not the whole struct) — the same
mechanism the existing communities `confirm_delete` relies on.
Test coverage for the key handlers lands in R26 slice 2 (stacked next), per the
task's verification note.
Gate: cargo fmt, clippy -D warnings, test --workspace all green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
added a commit
that referenced
this pull request
Jun 12, 2026
) * feat(ui): consistent y/Enter confirmation for destructive actions (R25) Communities and VTA-DID deletes already require a y/Enter confirmation, but `d` in Relationship detail, `d` in Credential detail, and `d`/`c` in the Inbox deleted or dismissed instantly. This applies the existing `confirm_delete: Option<…>` arm pattern to those three unguarded panels so every destructive action behaves the same way. - State (content.rs): add `RelationshipsState.confirm_delete: Option<String>` (remote_p_did), `CredentialsState.confirm_delete: Option<String>` (vrc_id), and `InboxState.confirm: Option<InboxConfirm>` where `InboxConfirm` is `Dismiss { task_id } | ClearAll` (covers both the single-dismiss and clear-all destructive paths). - Actions: new pure arming/cancel variants — `RelationshipAction::{ConfirmRemove, CancelRemove}`, `CredentialAction::{ConfirmRemove, CancelRemove}`, and `InboxAction::{ConfirmDismiss, ConfirmClearAll, CancelConfirm}`. Handled as pure state mutations in the respective `*_actions.rs` dispatchers (never network); the commit handlers (`prepare_remove`, `handle_remove`, `handle_dismiss_task`, `handle_clear_all`) clear the flag as the existing community/VTA-DID commits do. - Key handlers (main/mod.rs): the destructive keys now arm the confirmation; while one is pending, y/Enter commits and any other key cancels (Esc included), mirroring `handle_communities_key`/`handle_vta_key`. - Render: each panel footer shows the "… ? y: confirm n: cancel" prompt (orange/bold) while a confirmation is pending, matching the Communities panel. The confirm fields live on the panel state and survive `sync_from_config` (which updates the inner data vectors, not the whole struct) — the same mechanism the existing communities `confirm_delete` relies on. Test coverage for the key handlers lands in R26 slice 2 (stacked next), per the task's verification note. Gate: cargo fmt, clippy -D warnings, test --workspace all green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Glenn Gore <glenn.g@affinidi.com> * test(ui): main-page key-handler tests, one per panel (R26 slice 2) Slice 1 (#105) added table tests for the pure `*_actions.rs` mode handlers but deferred the main-page key-handler tests (they touched `main/mod.rs`, in flight for R23). This adds them now that R23/R25 have settled the file. Each test constructs a `MainPage` over a `State`, feeds a `KeyEvent` through the public `handle_key_event` entry point, and asserts on the `Action`(s) emitted on the channel. There is at least one test per content panel: - Communities, VTA-DID: confirmation commit (y/Enter) + cancel. - Inbox: `d`/`c` arm the dismiss / clear-all confirmation (R25), and a pending confirmation commits on y/Enter, cancels otherwise. - Relationships, Credentials: `d` in the detail view arms the removal (R25), and a pending confirmation commits the Remove. - Settings (Down moves selection), Logs, Help (Esc returns to the menu). `Action` and its sub-enums derive neither `PartialEq` nor `Debug`, so the tests pattern-match the expected variant. Stacked on R25 (#108) so the new destructive-confirm routing is exercised end-to-end. Gate: cargo fmt, clippy -D warnings, test --workspace all green (openvtc lib 113 -> 122 tests). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Glenn Gore <glenn.g@affinidi.com> --------- Signed-off-by: Glenn Gore <glenn.g@affinidi.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Communities and VTA-DID deletes require a
y/Enterconfirmation(
handle_communities_key/handle_vta_key), but three destructive actions fireinstantly:
din Relationship detail → removes the relationshipdin Credential detail → removes the VRCd(dismiss) andc(clear all) in the InboxFix
Apply the existing
confirm_delete: Option<…>arm pattern to all three panels.content.rs):RelationshipsState.confirm_delete: Option<String>(remote_p_did),
CredentialsState.confirm_delete: Option<String>(vrc_id),and
InboxState.confirm: Option<InboxConfirm>whereInboxConfirm = Dismiss { task_id } | ClearAll.RelationshipAction::{ConfirmRemove, CancelRemove},CredentialAction::{ConfirmRemove, CancelRemove},InboxAction::{ConfirmDismiss, ConfirmClearAll, CancelConfirm}. Handled aspure state mutations in the
*_actions.rsdispatchers (never network); thecommit handlers clear the flag exactly as the community/VTA-DID commits do.
main/mod.rs): the destructive keys arm the confirmation;while pending,
y/Entercommits and any other key (incl.Esc) cancels.… ? y: confirm n: cancel(orange/bold)while a confirmation is pending, matching the Communities panel.
The confirm fields live on the panel state and survive
sync_from_config(which updates the inner data vectors, not the whole struct) — the same
mechanism the existing communities
confirm_deleterelies on.Tests
Per the task's verification note ("key-handler tests if R26 has landed"), the
key-handler test coverage lands in R26 slice 2, stacked immediately after
this PR, exercising the new confirm flow end-to-end (one test per panel).
Gate
cargo fmt --all,cargo clippy --workspace --all-targets -- -D warnings,cargo test --workspace— all green.🤖 Generated with Claude Code