GovOPlaN/govoplan-mail
2
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

[Design review] Rework Mail server, envelope, credential, and policy structure #10

New Issue
Closed
opened 2026-07-11 03:46:50 +02:00 by zemion · 10 comments
zemion commented 2026-07-11 03:46:50 +02:00
Owner
Copy Link
Copy Source

Context

The mail backend now separates server configuration from credentials, but the profile creation/editing UI still behaves as if every edit button opens the same combined dialog.

Requested behavior

Change the mail profile creation and editing flow to reflect the server/credential split.

Acceptance criteria

  • Editing an IMAP server, SMTP server, and credentials opens the appropriate focused dialog.
  • The UI makes it clear that IMAP and SMTP can be different servers and server types.
  • Credentials are visibly attached to the server/profile they belong to.
  • Creation flow guides the user through server selection/creation and credential assignment without duplicating fields.
  • Existing profile policies remain compatible.
  • WebUI tests cover the new dialog routing and at least one create/edit path.

Folded Scope From #12: Mail Profile / Transport Complexity

The structural debt from govoplan-mail#12 is part of this redesign work and must not be lost while implementing the server/credential split.

Additional acceptance notes:

  • Extract mail profile policy merge and validation into smaller focused helpers with fixture-style tests.
  • Keep server configuration, credential inheritance, and policy enforcement visibly separate in the UI and backend service boundaries.
  • Split transport request preparation from execution/response handling where SMTP/IMAP behavior is touched.
  • Preserve existing policy compatibility while simplifying _merge_policy, update_mail_server_profile, _validate_policy_against_parent, list_imap_messages, and _send_smtp_payload over follow-up slices.

Source: folded from govoplan-mail#12 (source/security-audit, audit complexity baseline codex-audit-full-2026-07-11:mail-complexity-baseline).

## Context The mail backend now separates server configuration from credentials, but the profile creation/editing UI still behaves as if every edit button opens the same combined dialog. ## Requested behavior Change the mail profile creation and editing flow to reflect the server/credential split. ## Acceptance criteria - Editing an IMAP server, SMTP server, and credentials opens the appropriate focused dialog. - The UI makes it clear that IMAP and SMTP can be different servers and server types. - Credentials are visibly attached to the server/profile they belong to. - Creation flow guides the user through server selection/creation and credential assignment without duplicating fields. - Existing profile policies remain compatible. - WebUI tests cover the new dialog routing and at least one create/edit path. ## Folded Scope From #12: Mail Profile / Transport Complexity The structural debt from `govoplan-mail#12` is part of this redesign work and must not be lost while implementing the server/credential split. Additional acceptance notes: - Extract mail profile policy merge and validation into smaller focused helpers with fixture-style tests. - Keep server configuration, credential inheritance, and policy enforcement visibly separate in the UI and backend service boundaries. - Split transport request preparation from execution/response handling where SMTP/IMAP behavior is touched. - Preserve existing policy compatibility while simplifying `_merge_policy`, `update_mail_server_profile`, `_validate_policy_against_parent`, `list_imap_messages`, and `_send_smtp_payload` over follow-up slices. Source: folded from `govoplan-mail#12` (`source/security-audit`, audit complexity baseline `codex-audit-full-2026-07-11:mail-complexity-baseline`).
zemion commented 2026-07-12 01:36:08 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

Summary

  • Split the mail profile tree so SMTP/IMAP server settings and SMTP/IMAP credentials are visible as separate child rows, with edit actions opening the corresponding MailServerSettingsPanel section.
  • Added a WebUI package lock so the module-local test script can install and run TypeScript consistently.

Changed Files

  • webui/src/features/mail/MailProfileManagement.tsx
  • webui/package-lock.json

Verification

  • /home/zemion/.nvm/versions/node/v22.22.3/bin/npm run test:mail-ui
  • /home/zemion/.nvm/versions/node/v22.22.3/bin/npm run build in govoplan-core/webui

Next / Blocked

  • Keep this open for full guided creation/edit UX and any backend schema split work that is still intended for this issue.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Split the mail profile tree so SMTP/IMAP server settings and SMTP/IMAP credentials are visible as separate child rows, with edit actions opening the corresponding MailServerSettingsPanel section. - Added a WebUI package lock so the module-local test script can install and run TypeScript consistently. ### Changed Files - `webui/src/features/mail/MailProfileManagement.tsx` - `webui/package-lock.json` ### Verification - `/home/zemion/.nvm/versions/node/v22.22.3/bin/npm run test:mail-ui` - `/home/zemion/.nvm/versions/node/v22.22.3/bin/npm run build in govoplan-core/webui` ### Next / Blocked - Keep this open for full guided creation/edit UX and any backend schema split work that is still intended for this issue. Suggested status label: `status/in-progress`
zemion commented 2026-07-12 16:32:49 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: done

Summary

  • Mail profile UI now separates profile metadata, SMTP/IMAP server settings, and SMTP/IMAP credentials into focused edit targets.
  • The shared core MailServerSettingsPanel supports full, server-only, and credentials-only modes without duplicating fields.
  • Existing policy handling remains compatible; IMAP add/edit no longer treats credentials-only input as a configured IMAP server.

Changed Files

  • govoplan-core/webui/src/components/mail/MailServerSettingsPanel.tsx
  • govoplan-mail/webui/src/features/mail/MailProfileManagement.tsx
  • govoplan-mail/webui/src/features/mail/mailProfileEditorModel.ts

Verification

  • npm run test:mail-components (core WebUI)
  • npm run test:mail-ui (mail WebUI)
  • python -m unittest discover -s tests (govoplan-mail)
## Codex State: done ### Summary - Mail profile UI now separates profile metadata, SMTP/IMAP server settings, and SMTP/IMAP credentials into focused edit targets. - The shared core MailServerSettingsPanel supports full, server-only, and credentials-only modes without duplicating fields. - Existing policy handling remains compatible; IMAP add/edit no longer treats credentials-only input as a configured IMAP server. ### Changed Files - `govoplan-core/webui/src/components/mail/MailServerSettingsPanel.tsx` - `govoplan-mail/webui/src/features/mail/MailProfileManagement.tsx` - `govoplan-mail/webui/src/features/mail/mailProfileEditorModel.ts` ### Verification - `npm run test:mail-components (core WebUI)` - `npm run test:mail-ui (mail WebUI)` - `python -m unittest discover -s tests (govoplan-mail)`
zemion changed title from Mail: redesign profile UI around server and credential split to [Design review] Rework Mail server, envelope, credential, and policy structure 2026-07-28 00:58:11 +02:00
zemion reopened this issue 2026-07-28 00:58:11 +02:00
zemion commented 2026-07-28 00:58:11 +02:00
Author
Owner
Copy Link
Copy Source

Reopened as a design-review placeholder by product decision on 2026-07-28.

The current UI and backing hierarchy are not accepted as the final structure. In particular, server envelopes, concrete servers, reusable credential envelopes, attached credentials, visibility/inheritance, policies, and module-specific selections need a coherent model rather than another local UI adjustment.

Implementation is intentionally paused until the product owner adds the detailed structural notes. Existing code remains provisional; this issue should not be closed based only on the previously implemented split.

Reopened as a design-review placeholder by product decision on 2026-07-28. The current UI and backing hierarchy are not accepted as the final structure. In particular, server envelopes, concrete servers, reusable credential envelopes, attached credentials, visibility/inheritance, policies, and module-specific selections need a coherent model rather than another local UI adjustment. Implementation is intentionally paused until the product owner adds the detailed structural notes. Existing code remains provisional; this issue should not be closed based only on the previously implemented split. <!-- codex-mail-structure-pin-2026-07-28 -->
zemion commented 2026-07-29 02:29:55 +02:00
Author
Owner
Copy Link
Copy Source

Selector audit follow-up: the current credential editor still asks for comma-separated module IDs and server references. This should be addressed as part of the envelope/server/credential redesign using typed multi-select providers, while retaining unavailable and optional cross-module references. Cross-module tracking: GovOPlaN/govoplan-core#272.

Selector audit follow-up: the current credential editor still asks for comma-separated module IDs and server references. This should be addressed as part of the envelope/server/credential redesign using typed multi-select providers, while retaining unavailable and optional cross-module references. Cross-module tracking: GovOPlaN/govoplan-core#272.
zemion commented 2026-07-29 03:51:37 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

Summary

  • Completed the govoplan-core#272 reference slice: credential module restrictions are registry-backed and server restrictions use typed selectors.
  • Mail now announces accessible SMTP/IMAP servers through an optional Core UI capability, including inactive state and scope/profile provenance.

Changed Files

  • webui/src/features/mail/MailProfileManagement.tsx
  • webui/src/features/mail/mailReferenceProviders.ts
  • webui/src/module.ts

Verification

  • npm run test:mail-ui (passed)
  • full-product and mail-only module builds (passed)

Next / Blocked

  • Keep this issue open for the broader server/envelope/credential/policy redesign and complexity work already captured in its acceptance criteria.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Completed the govoplan-core#272 reference slice: credential module restrictions are registry-backed and server restrictions use typed selectors. - Mail now announces accessible SMTP/IMAP servers through an optional Core UI capability, including inactive state and scope/profile provenance. ### Changed Files - `webui/src/features/mail/MailProfileManagement.tsx` - `webui/src/features/mail/mailReferenceProviders.ts` - `webui/src/module.ts` ### Verification - `npm run test:mail-ui (passed)` - `full-product and mail-only module builds (passed)` ### Next / Blocked - Keep this issue open for the broader server/envelope/credential/policy redesign and complexity work already captured in its acceptance criteria. Suggested status label: `status/in-progress`
zemion commented 2026-07-29 13:26:00 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

The audit reinforces this design review: update_profile (D/23), _profile_response (D/21), and update_bound_mail_credential (D/27) still combine envelope/server/credential policy, visibility, secret updates, and response shaping. Treat their decomposition as acceptance work for the new server-envelope -> server -> reusable credential model rather than opening a parallel refactor ticket.

## Codex State: progress The audit reinforces this design review: `update_profile` (D/23), `_profile_response` (D/21), and `update_bound_mail_credential` (D/27) still combine envelope/server/credential policy, visibility, secret updates, and response shaping. Treat their decomposition as acceptance work for the new server-envelope -> server -> reusable credential model rather than opening a parallel refactor ticket.
zemion commented 2026-07-30 14:37:27 +02:00
Author
Owner
Copy Link
Copy Source

Product decision: intentionally postponed

This redesign remains important, but the current envelope -> server -> reusable credential hierarchy and inheritance model is not accepted as final and will not be extended piecemeal now. Keep the existing implementation operational and preserve the decomposition findings. Resume only when the complete visibility, inheritance, credential reuse, policy, and module-selection model is specified.

## Product decision: intentionally postponed This redesign remains important, but the current envelope -> server -> reusable credential hierarchy and inheritance model is not accepted as final and will not be extended piecemeal now. Keep the existing implementation operational and preserve the decomposition findings. Resume only when the complete visibility, inheritance, credential reuse, policy, and module-selection model is specified.
zemion commented 2026-07-30 21:48:55 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: ready

Summary

  • The current envelope/server/reusable-credential split is accepted for now.
  • Remaining work is the creation/editing workflow and UI presentation: make server and credential bindings explicit and understandable without another data-model redesign.

Suggested status label: status/ready

## Codex State: ready ### Summary - The current envelope/server/reusable-credential split is accepted for now. - Remaining work is the creation/editing workflow and UI presentation: make server and credential bindings explicit and understandable without another data-model redesign. Suggested status label: `status/ready`
zemion commented 2026-07-30 21:50:22 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: ready

Summary

  • The current envelope/server/reusable-credential split is accepted for now. Remaining work is the creation/editing workflow and UI presentation: make server and credential bindings explicit and understandable without another data-model redesign.

Suggested status label: status/ready

## Codex State: ready ### Summary - The current envelope/server/reusable-credential split is accepted for now. Remaining work is the creation/editing workflow and UI presentation: make server and credential bindings explicit and understandable without another data-model redesign. Suggested status label: `status/ready`
zemion commented 2026-07-30 22:32:20 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: done

Summary

  • Kept the accepted profile -> protocol server -> reusable credential hierarchy unchanged.
  • Editing profile metadata, SMTP/IMAP servers, and attached credentials uses separate focused dialogs and isolated update payloads.
  • Replaced the combined first-create form with a five-stage flow: profile, SMTP server, SMTP credential, optional IMAP server, and optional IMAP credential. The final create remains one atomic request.
  • The tree makes each credential's server binding explicit and supports creating or linking reusable credentials.

Verification

  • npm run test:mail-ui passed, including create-stage and focused-editor model tests.
  • Core full linked-module WebUI build and bundle-budget check passed.
## Codex State: done ### Summary - Kept the accepted profile -> protocol server -> reusable credential hierarchy unchanged. - Editing profile metadata, SMTP/IMAP servers, and attached credentials uses separate focused dialogs and isolated update payloads. - Replaced the combined first-create form with a five-stage flow: profile, SMTP server, SMTP credential, optional IMAP server, and optional IMAP credential. The final create remains one atomic request. - The tree makes each credential's server binding explicit and supports creating or linking reusable credentials. ### Verification - `npm run test:mail-ui` passed, including create-stage and focused-editor model tests. - Core full linked-module WebUI build and bundle-budget check passed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
HTTP API contracts, routers, schemas, or API smoke behavior.
 area/auth
Authentication, sessions, access bootstrap, or login behavior.
 area/db
Database sessions, models, transactions, or persistence primitives.
 area/devex
Local developer workflow, scripts, tests, tooling, or release helpers.
 area/docs
Durable documentation and project guidance.
 area/governance
Governance policy, audit, privacy, retention, or compliance behavior.
 area/marketing
Public website, product messaging, publication copy, or legal page content.
 area/migrations
Alembic migrations, schema bootstrap, or persistence evolution.
 area/module-system
Module discovery, manifests, capabilities, routing, or optional integrations.
 area/rbac
Permissions, roles, delegation, or authorization policy.
 area/release
Versioning, release locks, tags, packaging, or dependency pins.
 area/security
Security posture, static analysis, supply-chain hardening, or vulnerability remediation.
 area/tenancy
Tenant boundaries, provisioning, or tenant-scoped data behavior.
 area/webui
Shared WebUI shell, frontend components, routing, or frontend tests.
 audit/complexity
Complexity finding from Radon, Xenon, or equivalent maintainability scans.
 audit/duplication
Duplicated-code finding from jscpd or equivalent similarity scans.
 audit/false-positive
Audit finding reviewed as a narrow false positive or acceptable risk.
 audit/needs-design
Audit finding that needs an architectural or product decision before implementation.
 audit/quick-fix
Audit finding that appears narrow and directly fixable.
 audit/structural
Audit finding that needs design, refactoring, or behavior review.
 codex/needs-human
Needs an explicit human decision before Codex should implement.
 codex/ready
Suitable for Codex to pick up with the existing issue context.
 module/access
GovOPlaN access, identity, authentication, RBAC, and administration behavior.
 module/addresses
GovOPlaN Addresses module behavior or integration.
 module/admin
GovOPlaN Admin module behavior or integration.
 module/appointments
GovOPlaN Appointments module behavior or integration.
 module/approvals
GovOPlaN Approvals module behavior or integration.
 module/audit
GovOPlaN Audit module behavior or integration.
 module/calendar
GovOPlaN Calendar module behavior or integration.
 module/campaign
GovOPlaN campaign module behavior or integration.
 module/cases
GovOPlaN Cases module behavior or integration.
 module/committee
GovOPlaN Committee module behavior or integration.
 module/connectors
GovOPlaN Connectors module behavior or integration.
 module/core
GovOPlaN core runner, shared primitives, shell, or extension points.
 module/dashboard
GovOPlaN Dashboard module behavior or integration.
 module/dataflow
GovOPlaN Dataflow module behavior or integration.
 module/datasources
GovOPlaN governed datasource contracts, catalogs, and integrations.
 module/decisions
GovOPlaN formal Decisions module behavior or integration.
 module/dist-lists
GovOPlaN Distribution Lists module behavior or integration.
 module/dms
GovOPlaN Dms module behavior or integration.
 module/docs
GovOPlaN Docs module behavior or integration.
 module/encryption
GovOPlaN Encryption key custody, cryptographic policy, and E2EE integration.
 module/erp
GovOPlaN Erp module behavior or integration.
 module/evaluation
GovOPlaN Evaluation module behavior or integration.
 module/files
GovOPlaN files module behavior or integration.
 module/fit-connect
GovOPlaN Fit Connect module behavior or integration.
 module/forms
GovOPlaN Forms module behavior or integration.
 module/forms-runtime
GovOPlaN Forms Runtime module behavior or integration.
 module/helpdesk
GovOPlaN Helpdesk module behavior or integration.
 module/identity
GovOPlaN Identity module behavior or integration.
 module/identity-trust
GovOPlaN Identity Trust module behavior or integration.
 module/idm
GovOPlaN Idm module behavior or integration.
 module/ledger
GovOPlaN Ledger module behavior or integration.
 module/mail
GovOPlaN mail module behavior or integration.
 module/mandates
GovOPlaN Mandates, jurisdiction, responsibility, and authority behavior or integration.
 module/notifications
GovOPlaN Notifications module behavior or integration.
 module/ops
GovOPlaN Ops module behavior or integration.
 module/organizations
GovOPlaN Organizations module behavior or integration.
 module/parties
GovOPlaN procedure Parties, representation, and delivery-authority behavior or integration.
 module/payments
GovOPlaN Payments module behavior or integration.
 module/permits
GovOPlaN Permits module behavior or integration.
 module/policy
GovOPlaN Policy module behavior or integration.
 module/poll
GovOPlaN Poll module behavior or integration.
 module/portal
GovOPlaN Portal module behavior or integration.
 module/postbox
GovOPlaN Postbox module behavior or integration.
 module/projects
GovOPlaN Projects module behavior or integration.
 module/quick-access
GovOPlaN configurable task-local Quick Access behavior and integrations.
 module/records
GovOPlaN Records and eAkte lifecycle behavior or integration.
 module/reporting
GovOPlaN Reporting module behavior or integration.
 module/risk-compliance
GovOPlaN Risk Compliance module behavior or integration.
 module/scheduling
GovOPlaN Scheduling module behavior or integration.
 module/search
GovOPlaN Search module behavior or integration.
 module/services
GovOPlaN versioned institutional Services behavior or integration.
 module/tasks
GovOPlaN Tasks module behavior or integration.
 module/templates
GovOPlaN Templates module behavior or integration.
 module/tenancy
GovOPlaN Tenancy module behavior or integration.
 module/tickets
GovOPlaN Tickets module behavior or integration.
 module/views
GovOPlaN governed task views, interface projections, and workflow view integration.
 module/voting
GovOPlaN Voting module behavior or integration.
 module/wiki
GovOPlaN Wiki module behavior or integration.
 module/workflow
GovOPlaN Workflow module behavior or integration.
 module/workflow-engine
GovOPlaN Workflow Engine runtime, persistence, or integration.
 module/xoev
GovOPlaN Xoev module behavior or integration.
 module/xrechnung
GovOPlaN Xrechnung module behavior or integration.
 module/xta-osci
GovOPlaN Xta Osci module behavior or integration.
priority
p0
Immediate stop-the-line priority.
priority
p1
High priority for the next focused work window.
priority
p2
Normal planned priority.
priority
p3
Low priority or opportunistic cleanup.
source/backlog-import
Imported from markdown backlog, roadmap, plan, or TODO files.
 source/security-audit
Created from a structured security or code-quality audit report.
 source/todo-scan
Imported from inline TODO/FIXME/HACK markers by the Gitea TODO importer.
status
blocked
Cannot progress without a decision, dependency, credential, or external change.
status
in-progress
Currently being worked.
status
needs-info
Needs clarifying input before implementation can proceed safely.
status
ready
Ready for implementation.
status
triage
Needs review, ownership, priority, or acceptance criteria.
type
bug
A reproducible defect, regression, or incorrect behavior.
type
debt
Cleanup, refactoring, risk reduction, or deferred engineering work.
type
docs
Documentation, process, or developer workflow work.
type
feature
New user-visible behavior or platform capability.
type
task
Implementation, maintenance, migration, or operational work.
type
user-story
End-to-end user journey or real-world process story used to steer product slices.
No labels area/governance area/security codex/needs-human module/mail
priority
p2
 source/security-audit
status
needs-info
type
task
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
govoplan-package-publisher zemion (Albrecht Degering)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-mail#10