Privacy Policy - Worklog Rescue for Jira
This Privacy Policy explains how personal data is processed in connection with Worklog Rescue (the “App”), an Atlassian Forge application for Atlassian Jira Cloud. The App is published on the Atlassian Marketplace. This Policy is written to comply with Regulation (EU) 2016/679 (the “GDPR”) and the Polish Act on Personal Data Protection of 10 May 2018.
1. Controller / data-processing contact
Worklog Rescue is operated as a sole proprietorship (jednoosobowa działalność gospodarcza) registered in Poland.
| Trader name | Paweł Woliński FiniteSolution (sole proprietor) |
|---|---|
| Business address | ul. Jerzego Popiełuszki 9/2, 44-109 Gliwice, Poland |
| NIP (Polish tax ID) | 9691656072 |
| Contact email | pawel.wolinski@int.pl |
| Privacy contact | pawel.wolinski@int.pl (no separate DPO is appointed, as appointment is not mandatory at the App’s current scale under Art. 37 GDPR) |
For all matters regarding personal data, including the exercise of the rights described in Section 9, please contact the privacy email above. We will respond within one month of receipt, in accordance with Art. 12(3) GDPR.
2. Scope of this Policy
This Policy applies to personal data processed by the App when it is installed on an Atlassian Jira Cloud site by a customer (“Customer”). It does not cover:
- Processing carried out independently by Atlassian Pty Ltd as part of the Jira Cloud or Atlassian Marketplace services. Atlassian’s own privacy notice governs that processing.
- Processing carried out by the Customer in their use of Jira independently of the App.
- Visits to any marketing pages or websites operated by the Trader outside the App itself (a separate notice will apply if and when such pages are published).
3. Roles under the GDPR
In the great majority of processing carried out by the App, the Customer is the controller of the personal data (it relates to the Customer’s Jira users, projects, and worklogs) and the Trader acts as processor on the Customer’s behalf within the meaning of Art. 4(8) GDPR. The Trader processes that data only for the purposes set out in Section 5 and on the documented instructions implicit in the act of installing and using the App.
The Trader acts as an independent controller for a narrow set of contact data - for example, the email of a person who contacts us with a privacy enquiry or a support request. That data is processed under the legal basis described in Section 5 (legitimate interest).
A separate Data Processing Agreement (DPA) that reflects the processor relationship is available on request to the privacy email above. We will sign a DPA with any Customer that requires one before or during the term of their installation.
4. Categories of personal data processed
The App processes only data already present in the Customer’s Jira site, plus a small amount of configuration the user enters in the App itself. No “special category” data within the meaning of Art. 9 GDPR is processed, and the App does not request location data, payment data, or device identifiers.
| Category | Examples | Source |
|---|---|---|
| Jira account identifiers | Atlassian accountId, display name, avatar URL as exposed by Jira’s REST API | Jira (read via the user’s existing permissions) |
| Issue activity metadata | Issue keys and summaries, worklog timestamps and durations, comment author identifier + creation timestamp (not the comment text), status-change events authored by the user, assignment events | Jira (read via the user’s existing permissions) |
| Submitted worklogs | Issue key, date, duration in seconds, optional comment text entered by the user | Created by the user inside the App, written back to Jira |
| Workspace configuration | Excluded issue types, working days, default daily target | Entered by a user (typically a Jira administrator) in the App’s Settings; applies to all users of the installation |
| Personal configuration | Selected projects (per user), personal daily-target override, preferred quick-log durations, “show low-confidence suggestions” toggle, theme preference | Entered by the calling user in the App’s Settings; applies only to that user |
| Drafts | Issue key, date, duration, optional comment, denormalised issue summary for the UI | Created by the user inside the App |
| Ignored-issue marks | Issue key + month + reason text + timestamp | Created by the user inside the App |
| Idempotency mappings | Internal clientKey → Jira worklog ID pairs created at the moment of submission | Generated by the App at submission time |
| Reminder state | Per-user flag + timestamps used by the in-app month-end banner | Generated by the App |
| Performance caches | Pre-computed monthly scan results and per-issue scoring inputs, keyed by Atlassian accountId and month | Derived from the Jira data above |
The App does not store, log, or transmit onward: comment text, issue descriptions, attachments, full worklog history beyond what is needed for the current month, browser history, mouse or keyboard activity, screenshots, IP address, or any data outside the Customer’s Jira site.
Where the Jira REST API returns a payload that includes such fields (for example, the issue-comments endpoint returns the full comment body as part of its standard response), the App’s code parses only the metadata it needs - for comments, this is the author identifier and the creation timestamp, which together allow the App to recognise that the current user participated in a discussion during the selected month. The remaining fields, including the comment body, are discarded; they are neither saved to Forge storage, written to logs, sent to the App’s frontend, nor transmitted to any third party.
5. Purposes of processing and legal bases (Art. 6 GDPR)
| Purpose | Legal basis | Notes |
|---|---|---|
| Reading Jira activity to surface likely worked-on issues for the current user | Art. 6(1)(b) - performance of the contract between the Customer and the Trader | The user’s existing Jira access permissions are respected at all times; the App never bypasses them. |
| Storing App configuration, drafts and ignored-issue marks | Art. 6(1)(b) - performance of the contract | Required for the App to function. |
| Writing worklogs to Jira on the user’s behalf | Art. 6(1)(b) - performance of the contract | Always preceded by an explicit user action (Submit or quick-log click). |
| Operational logging of errors (without ticket content) and idempotency mappings to prevent duplicate worklog creation | Art. 6(1)(f) - legitimate interest in providing a reliable service | Logs do not contain ticket content. |
| Responding to support and privacy enquiries | Art. 6(1)(f) - legitimate interest in providing support | We retain only the correspondence necessary to handle the request. |
| Complying with legal obligations (e.g., responding to lawful requests from supervisory authorities) | Art. 6(1)(c) - legal obligation | Applies only when invoked. |
No processing is carried out on the basis of consent under Art. 6(1)(a), and consequently there is no consent to withdraw. No processing involves automated decision-making or profiling within the meaning of Art. 22 GDPR.
6. Recipients and sub-processors
The App stores all data inside the Atlassian Forge platform’s managed key-value storage. The data does not leave the Atlassian-managed environment as a result of the App’s operation; the Trader does not operate any backend server, database, or analytics pipeline of its own.
| Sub-processor | Role | Location of processing |
|---|---|---|
| Atlassian Pty Ltd (publisher of Forge and Jira Cloud) | Hosts the App’s code, executes its functions, and stores its data in Forge key-value storage | Regional Atlassian data centres on Amazon Web Services. Atlassian’s current sub-processor list and data-residency commitments are published at atlassian.com/legal/sub-processors |
No third party other than Atlassian processes personal data on the Trader’s behalf. The Trader does not sell, rent, or share personal data for marketing or any other purpose unrelated to operating the App.
If the Trader engages an additional sub-processor in the future (for example, a hosted error-tracking service), this Policy will be updated and Customers will be informed via the Atlassian Marketplace listing before the change takes effect, in accordance with the DPA where one is in place.
7. International transfers
Because all data is stored and processed inside Atlassian’s Forge platform, international transfer of personal data - if any - is governed by Atlassian’s own transfer mechanisms, which include the Standard Contractual Clauses adopted by the European Commission (Decision 2021/914). Customers may choose a data-residency region within Atlassian’s Cloud where supported.
The Trader itself, operating from Poland, does not transfer data outside the European Economic Area in connection with the App.
8. Retention
The Trader keeps personal data only for as long as needed for the purposes set out in Section 5.
| Data | Retention |
|---|---|
| Submitted worklogs | Live in Jira, not in App storage. Their retention is governed by the Customer’s Jira configuration. |
| Drafts | Kept until the user submits, deletes, or clears them. Submission removes the draft immediately. |
| Ignored-issue marks | Kept for up to 12 months per (user, month) pair. |
| Workspace and user settings | Kept for the duration of the App’s installation. Removed on App uninstall. |
| Idempotency mappings | Kept for up to 90 days after the corresponding worklog is created, then pruned. |
| Performance caches | Per-issue cache entries self-invalidate on Jira-side change; monthly scan cache expires after 5 minutes. Both are pruned in bulk on App uninstall. |
| Support / privacy correspondence | Kept for as long as needed to handle the matter, plus the limitation period applicable to potential claims under the Polish Civil Code. |
On App uninstall by the Customer’s Jira administrator, the Trader will arrange for App storage relating to that installation to be deleted from Forge within 30 days. Customers may request earlier deletion at any time via the privacy email above.
9. Rights of data subjects
Under Arts. 15–22 and Art. 77 GDPR, every individual whose personal data is processed in connection with the App has the following rights:
- Right of access (Art. 15) - to obtain confirmation of whether personal data concerning them is processed and a copy of that data.
- Right to rectification (Art. 16) - to have inaccurate data corrected and incomplete data completed.
- Right to erasure (“right to be forgotten”, Art. 17) - to have personal data deleted in the circumstances listed in that Article.
- Right to restriction of processing (Art. 18) - to have processing limited in the circumstances listed in that Article.
- Right to data portability (Art. 20) - to receive personal data provided to us in a structured, commonly used and machine-readable format, and to transmit it to another controller.
- Right to object (Art. 21) - to object at any time, on grounds relating to one’s particular situation, to processing based on legitimate interest.
- Right not to be subject to automated decision-making (Art. 22) - already satisfied: no such processing is carried out.
- Right to lodge a complaint with a supervisory authority (Art. 77) - in Poland the competent authority is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO), ul. Stawki 2, 00-193 Warsaw, uodo.gov.pl.
To exercise these rights, please write to the privacy email in Section 1. We will verify the identity of the requester (typically by checking that the request comes from an email associated with the relevant Atlassian account) and respond within one month, extending by a further two months only where strictly necessary under Art. 12(3) GDPR.
Where the Trader acts as a processor (Section 3) and the request concerns data the Customer controls, the Trader will either forward the request to the Customer or instruct the requester to contact the Customer directly, as required by Art. 28(3)(e) GDPR. Where appropriate the Trader will assist the Customer in fulfilling its own obligations under Arts. 15–22.
In addition to GDPR rights, the App’s Settings include a “Clear my data” action that erases the calling user’s App-stored data (drafts, ignored-issue marks, user settings, reminder state, cached scoring inputs) from Forge storage. This is provided for convenience; it does not affect the user’s GDPR rights described above.
10. Security measures
The App is built using Atlassian Forge, which provides:
- Encryption of data in transit (TLS) and at rest within the Forge platform.
- Isolation of each installation’s data per Atlassian Cloud site.
- Enforcement of Jira’s own permission model: the App reads only data the calling user could already read in Jira, and writes only data the calling user could already write.
In addition, the Trader has adopted the following measures:
- The Forge manifest declares the minimum scopes necessary for the App to function:
read:jira-work,write:jira-work,read:jira-user,storage:app. No administrator scopes are requested. - The manifest declares no
external-fetchentries. The App makes no outbound network calls to third parties. - Error logs are designed to omit ticket content (issue descriptions, comment bodies, worklog comments).
- Idempotency tokens are used at every submission boundary to prevent duplicate worklog creation.
- All App source is held in a private repository under standard access controls. Production deploys are made only from clean builds that have passed lint, typecheck, and the automated test suite.
In the event of a personal-data breach affecting the App, the Trader will notify the competent supervisory authority within 72 hours of becoming aware, in accordance with Art. 33 GDPR, and will notify affected Customers and data subjects without undue delay in accordance with Arts. 33–34 GDPR.
11. No surveillance commitment
The App is designed around an explicit commitment not to be a workplace surveillance tool. It does not and will not:
- Capture screenshots, screen recordings, browser history, or page contents outside the App’s own UI.
- Track keystrokes, mouse movement, or active-window state.
- Run any kind of background timer or “always-on” tracking.
- Apply productivity scoring, ranking, or comparison of one user against another.
- Send any data to third-party analytics, advertising, marketing-automation, or behavioural-tracking services.
If any future feature were to require any of the above, it would be introduced only with prior notice, an updated policy, and (where required by law) freely given consent.
12. Changes to this Policy
The Trader may update this Policy from time to time, for example to reflect changes in the App’s functionality, in applicable law, or in the Atlassian sub-processor list. The latest version is always published at the canonical URL referenced from the App’s Atlassian Marketplace listing and inside the App’s Settings screen.
When changes are material - for example, the addition of a new sub-processor, a new category of personal data, or a new processing purpose - the Trader will give Customers reasonable advance notice (no less than 30 days where feasible) through the Marketplace listing and, where a DPA is in place, in the manner required by that agreement.
The version and effective date at the top of this document indicate when this Policy was last revised.
13. Questions and complaints
Privacy questions and rights requests: pawel.wolinski@int.pl
If you are not satisfied with the Trader’s response, you have the right to lodge a complaint with the competent supervisory authority (in Poland, the President of the Personal Data Protection Office - see Section 9).