Totesoft Documentation

Espresso Privacy and Security

Status: customer-facing draft; publish only after the run-history error-detail release gate is resolved and the legal page is corrected.

Hosting and external egress

Espresso is an Atlassian Forge app for Jira Cloud. The reviewed manifest declares no external network egress and no Totesoft-hosted remote application backend.

Data processed during configuration

The Custom UI requests Jira field metadata and filters the list to numeric schemas. A saved rule contains:

• Source Field 1 ID and display name;
• Source Field 2 ID and display name;
• operator;
• Target Field ID and display name; and
• configuration schema version.

Data processed during a transition

Espresso processes:

• issue ID and issue key;
• transition ID and name;
• the two configured numeric source values;
• the computed numeric result; and
• target field ID.

The source values and calculated result are used during execution. They are not explicit fields in the Recent runs record.

Jira writes

Espresso updates only the configured target field. It does not intentionally create comments, attachments, worklogs, links, users, projects, workflows, or transitions, and it does not transition or delete issues.

The update requests notifyUsers=false. Jira decides whether notification suppression is honored.

Forge hosted storage

Espresso stores up to 10 recent diagnostic records for each field-triple key. A record may contain:

• timestamp;
• issue key;
• transition ID/name;
• operation;
• outcome code, severity, and summary;
• technical detail;
• retry count; and
• duration.

The history is bounded and is not a complete audit log.

Current error-detail release gate

The current update handler can pass Jira’s raw rejection body into normal outcome detail. That detail is then logged and can be persisted in the run history, truncated to the outcome limit. Jira error text can quote customer-derived content.

Before publication, Totesoft must either:

1. sanitize detail to a fixed allowlist of status, field ID, and error category; or
2. explicitly disclose raw rejection text in the privacy notice and Marketplace answers.

The preferred option is sanitization.

Logs

Authorized Totesoft personnel can access Forge application logs.

Normal structured logs can contain:

• issue key;
• transition ID;
• rule key derived from field IDs;
• outcome, severity, and detail;
• retry count; and
• duration.

When the ESPRESSO_DEBUG Forge variable is explicitly set to true, current debug calls can additionally include numeric source values and the calculated result. Raw Jira rejection text is a separate current issue: it can enter normal outcome detail even when debug is off. Debug mode must be disabled by default, enabled only for an approved investigation, and removed immediately afterward.

The Marketplace answer to “Does the app log End-User Data?” should be Yes, with a precise explanation.

External sharing

The reviewed implementation sends no data to third-party analytics, advertising, AI, or monitoring services. Atlassian provides Jira Cloud, Forge execution, hosted storage, and logs under the customer’s Atlassian relationship.

Uninstall and retention

Forge hosted storage is installation-scoped. Atlassian’s newer Storage overview, updated August 21, 2026, states that hosted storage is retained for 28 days after uninstall. A new installation does not automatically recover it. With customer consent, a developer must submit a recovery request within 21 days so Atlassian can process it before retention ends.

An older Atlassian hosted-storage lifecycle page still displays a different 60-day statement. Use the newer Storage overview for this draft, but confirm the applicable period with Atlassian when the Marketplace form is submitted.

Security reports

Until a dedicated security address is approved, send reports to info@totesoft.com with the subject Espresso Security Report. Do not include live customer data or secrets in the initial message.