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
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.
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Present the creation workflows needed for base
passcompatibility without moving their rules into the desktop app.Scope
.gpg-idbehavior, encryption, generation policy, and commits remain incrates/storage.Acceptance criteria
Implemented and verified in commit
bb650c2.What changed:
Review:
Verification:
All required gates passed.