Present store initialization and entry creation workflows #38

New Issue

hugo · 2026-08-09T19:30:16Z

hugo commented

2026-08-09 19:30:16 +00:00

Goal

Present the creation workflows needed for base pass compatibility without moving their rules into the desktop app.

Scope

Add guided UI for initializing a store, selecting recipients/default key, creating folders where supported by storage, inserting a new entry, and generating/replacing a password.
Collect user choices and invoke typed storage commands; recipient validation, .gpg-id behavior, encryption, generation policy, and commits remain in crates/storage.
Offer generated results directly in the structured editor before save where the storage API supports that flow.
Confirm destructive replacement and clearly report validation, encryption, and persistence failures.
Expose every workflow through the appropriate menu/toolbar/context action and the command palette.

Acceptance criteria

A user can initialize/open a store and create or generate an entry without using the CLI or an external process.
Initialization and recipient choices round-trip through upstream-compatible storage behavior.
Cancellation and failures leave the store and current editor state unchanged.
The GUI does not duplicate password generation or recipient-selection rules.

## Goal Present the creation workflows needed for base `pass` compatibility without moving their rules into the desktop app. ## Scope - Add guided UI for initializing a store, selecting recipients/default key, creating folders where supported by storage, inserting a new entry, and generating/replacing a password. - Collect user choices and invoke typed storage commands; recipient validation, `.gpg-id` behavior, encryption, generation policy, and commits remain in `crates/storage`. - Offer generated results directly in the structured editor before save where the storage API supports that flow. - Confirm destructive replacement and clearly report validation, encryption, and persistence failures. - Expose every workflow through the appropriate menu/toolbar/context action and the command palette. ## Acceptance criteria - A user can initialize/open a store and create or generate an entry without using the CLI or an external process. - Initialization and recipient choices round-trip through upstream-compatible storage behavior. - Cancellation and failures leave the store and current editor state unchanged. - The GUI does not duplicate password generation or recipient-selection rules.

hugo added this to the 03 - Cross-platform Iced desktop app milestone 2026-08-09 19:30:16 +00:00

hugo added the enhancement label 2026-08-09 19:30:16 +00:00

hugo commented

2026-08-10 16:59:00 +00:00

Implemented and verified in commit bb650c2.

What changed:

Added guided desktop workflows for root store initialization, nested recipient-backed folder creation, collision-safe new-entry drafts, and generated password creation/replacement.
Recipient and default-key choices are loaded from storage-owned key metadata. Root and nested policies use RecipientPolicyManager, exact upstream .gpg-id serialization, selective re-encryption, and embedded automatic Git commits.
Default-key configuration replacement is coordinated with recipient-policy commit rollback so validation or commit failures do not leave the store/editor partially changed.
New entries open as structured unsaved documents; no repository bytes are written until Save succeeds. Existing-entry collisions are rejected, and generated passwords are placed directly in the editor.
Password length/symbol choices invoke GeneratorConfig. Existing values require explicit replacement confirmation.
Initialize Store, New Folder, New Entry, and Generate Password are shared across native/in-window menus, toolbar or field context actions, shortcuts where applicable, and the fuzzy command palette.
Fixed root-path selection in the embedded automatic Git committer so root pass init commits correctly for every frontend.

Review:

Recipient validation, path rules, .gpg-id behavior, generation, encryption, persistence, rollback, and Git remain in crates/storage.
The desktop app only collects choices and presents typed results; it launches no processes and adds no unsafe Rust.
Cancellation, invalid paths, creation failures, collisions, stale writes, and unconfirmed replacements preserve repository bytes and editor drafts.
Regression tests cover empty root initialization, exact nested policy bytes, default-key config reload, clean embedded Git commits, unsaved/generated drafts, collisions, cancellation/failure retention, palette discovery, and selected-field-only replacement.

Verification:

cargo fmt --all -- --check
RUSTFLAGS="-D warnings" cargo check --workspace --all-targets
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

All required gates passed.

Implemented and verified in commit bb650c2. What changed: - Added guided desktop workflows for root store initialization, nested recipient-backed folder creation, collision-safe new-entry drafts, and generated password creation/replacement. - Recipient and default-key choices are loaded from storage-owned key metadata. Root and nested policies use RecipientPolicyManager, exact upstream .gpg-id serialization, selective re-encryption, and embedded automatic Git commits. - Default-key configuration replacement is coordinated with recipient-policy commit rollback so validation or commit failures do not leave the store/editor partially changed. - New entries open as structured unsaved documents; no repository bytes are written until Save succeeds. Existing-entry collisions are rejected, and generated passwords are placed directly in the editor. - Password length/symbol choices invoke GeneratorConfig. Existing values require explicit replacement confirmation. - Initialize Store, New Folder, New Entry, and Generate Password are shared across native/in-window menus, toolbar or field context actions, shortcuts where applicable, and the fuzzy command palette. - Fixed root-path selection in the embedded automatic Git committer so root pass init commits correctly for every frontend. Review: - Recipient validation, path rules, .gpg-id behavior, generation, encryption, persistence, rollback, and Git remain in crates/storage. - The desktop app only collects choices and presents typed results; it launches no processes and adds no unsafe Rust. - Cancellation, invalid paths, creation failures, collisions, stale writes, and unconfirmed replacements preserve repository bytes and editor drafts. - Regression tests cover empty root initialization, exact nested policy bytes, default-key config reload, clean embedded Git commits, unsaved/generated drafts, collisions, cancellation/failure retention, palette discovery, and selected-field-only replacement. Verification: - cargo fmt --all -- --check - RUSTFLAGS="-D warnings" cargo check --workspace --all-targets - cargo clippy --workspace --all-targets -- -D warnings - cargo test --workspace All required gates passed.

hugo closed this issue

2026-08-10 16:59:09 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hugo/IronStorage#38