Hosting and data boundary
HandoffPing runs on Atlassian Forge. App code runs in Forge and reminder records use Forge hosted storage. There is no external app backend, external database, third-party email service, or third-party analytics service in the current app build.
Jira sends notifications through its own notification API. The Trust Center is a public documentation site and does not receive reminder content from the app.
Jira permissions
The Forge manifest requests these scopes:
- storage:app to store reminder schedules and delivery state in Forge hosted storage;
- read:jira-work to read the issue status, summary, project, and current assignee needed for delivery;
- read:jira-user to find Jira users selected as recipients;
- send:notification:jira to ask Jira to deliver the reminder; and
- report:personal-data to support Atlassian's personal-data reporting and closed-account lifecycle.
Input and scheduling controls
Reminder input is checked again in the Forge resolver, not only in the browser. Reminder messages must contain 1 to 500 characters. Recipient selections are normalized, deduplicated, and limited to 10 recipient selectors. Account identifiers must be non-empty strings.
Scheduled timestamps must be valid RFC 3339 instants in the future and no more than 365 days ahead. Time zones must be valid IANA time zones, and recurrence values are accepted only from the app's supported set. Request and reminder IDs are validated against fixed formats.
Access and notification safeguards
Reminder lists are filtered for the current Jira user. The app checks reminder access before edit, cancellation, and retry operations. Administration features require Jira administrator authorization.
Before delivery, the app reads the current issue state. A completed issue stops a recurring reminder. Jira notifications include a Browse permission restriction so Jira applies issue visibility when recipients open the work item.
Software and operational controls
Application dependencies are pinned with an npm lockfile. The release process includes an automated dependency audit gate for High and Critical advisories. Findings are reviewed before release rather than represented as a permanent guarantee that no vulnerability exists.
Delivery work uses bounded queues and retry-safe state changes. Operational logs are designed to avoid reminder text, Jira issue keys, and Atlassian account IDs. The app keeps only pseudonymous reminder identifiers and operational status needed to diagnose a delivery attempt.
Report a security issue
Email security@m51works.com with the suspected impact and safe reproduction steps. Do not include passwords, API tokens, authentication links, or data from another Jira organization. Security reports are prioritized.