Setup and everyday use

Use this guide after the Marketplace release; the app is not yet available for installation.

Set up a project

1. After release, an authorized Jira administrator installs the app through Atlassian Marketplace and reviews the requested permissions. Billing and evaluation terms appear in that official flow.
2. A project administrator opens Project settings → Working Day Guard. Confirm the license notice.
3. Start OFF. Choose weekdays, NEXT or PREVIOUS direction and a maximum search distance of 1–366 days.
4. Enter one closure per line as YYYY-MM-DD, or a range as YYYY-MM-DD..YYYY-MM-DD. Optional labels are no longer accepted. Explicit working-date overrides take precedence over closures/weekdays.
5. Test a date against the draft. Preview neither publishes settings nor edits an issue.
6. Publish OBSERVE. Wait beyond the 60-second policy activation guard, then create or explicitly change a synthetic issue's standard Due date. Review OBSERVED in the current visible audit.
7. Publish ENFORCE only when ready. After the same guard, an eligible new event may produce ADJUSTED. Jira's issue history is authoritative for actual writes. Refresh audit without discarding a draft.

Worked calendar example

With Monday–Friday working, closure 2026-09-21, NEXT direction and a 14-day search limit, Saturday 2026-09-19 previews Tuesday 2026-09-22. An explicit working override for 2026-09-21 instead makes Monday 2026-09-21 the target. PREVIOUS searches in the opposite direction. A working date stays unchanged; no date is chosen if the search limit contains no working day.

Troubleshooting and limits

• No correction: check mode, license, activation guard, relevant issue event and Jira permissions. Stale events, concurrent policy/issue changes and unavailable verification can cause a safe skip.
• Delays: event delivery and bounded retries are asynchronous; do not repeatedly edit the same issue to force the app. No end-to-end correction deadline is promised.
• Settings conflict: reload the current revision, reapply the intended edit and preview again.
• Old label input: reload settings and enter dates/ranges only. The pre-release implementation explicitly rejects non-empty labels; it does not silently discard them.
• Existing labelled dates: their old values stay in the same record and original retention. The editor shows the date, not an editable name. Weekdays, modes and unlabelled dates remain editable. Removing/moving a date with a retained value needs a separate existing-data instruction. Authorized return still includes old values. This is not a migration or erasure.
• Empty audit: recent audit examines at most 25 candidates and filters by retention and current issue visibility. An empty list is not proof that no records exist or that no write occurred.
• Inactive/unavailable license: configuration and preview are disabled; current settings and visible audit remain readable where the installation/Jira remain accessible. No historical rescan follows.
• Shared calendars: another project has its own settings. Holidays are manual; the app does not download or maintain a national holiday calendar.

Data requests and stopping

The ordinary project page has bounded data-response controls. Inspect the requested scope, pause/confirmation requirements and PARTIAL status. They cover authorized visible data, not all installation records. Clear returned data from the page when done and store any necessary copy securely.

Full managed-catalog requests use a separately authorized administrator workflow with a signed customer instruction, bounded pages and explicit acknowledgments. No unrestricted KVS dump or immediate deletion is promised. Legacy data and supplier logs/backups need separate handling. Contact privacy@rillnook.com for scope and authority checks.

For ordinary paid operation, publish OFF to stop future project event processing. OFF does not delete stored data, stop installation-wide maintenance or cancel a Jira request already sent. A paused data-request project resumes only into OFF; ENFORCE requires a separate explicit publication. Uninstall affects the whole installation and must be decided by its authorized administrator.

For help, contact support@rillnook.com. Send synthetic reproduction steps, mode and a safe error class. Do not send tokens, cookies, identity documents or unrestricted exports.

PDR_HOLD and an existing customer data request

In the local, undeployed recovery candidate, STATUS shows the hold and the next action. If an existing request can still be fulfilled, obtain a new signed grant for the same instruction, recipient and scope from the authorized issuer, then use RENEW. The backend rechecks present administration rights, installation, copy binding and revision. Old signatures/nonces do not become valid again. This resumes the customer instruction only: it cannot reset or blindly resend an uncertain PDR report. Ordinary expiry and valid deletion instructions are not extended. Received PDR instructions take precedence over an incompatible renewal. HOLD is not proof of completion; an overdue unacknowledged return still needs the existing instruction review.