Redmine issues and journals

Credentials travel in the X-Redmine-API-Key header and stay out of the URL. HTTPS and certificate verification are mandatory, redirects are rejected, requests time out and response bodies are bounded to 8 MiB. The existing Keen ingestion network policy applies, including KEEN_INGESTION_ALLOWED_CIDRS for private networks. There is no option to disable TLS checks.

Administrators can also manage config/redmine.yml; saved web-UI configuration overrides it, so use the UI consistently once an override exists. Shared adapter settings are editable in the source/connection management view.

ui_name: Redmine
badge_color: '#B73939'
projects:
  - project: '*'
    # label: Issue management
include_journals: true
initial_lookback_days: 0
overlap_seconds: 300
max_pages: 1000
full_scan_hours: 24

initial_lookback_days: 0 fetches all existing issues on the first run. A positive number limits that initial selection to recently updated issues, while all accessible journals of those issues are retained, including older comments. This initial lower bound is stored with the project cursor and retained during periodic reconciliation; changing it later does not reset existing cursors.

Incremental scans query issues updated since the previous successful scan, with a five-minute overlap by default. A full reconciliation runs every 24 hours by default, within the recorded history window, and can detect edits to older journals even when an issue's updated timestamp was not changed. Records absent from Redmine are not deleted from Keen, and a polling adapter cannot reconstruct deleted comments or intermediate states that disappeared between polls.

Pagination reads up to 100 records per page. max_pages bounds each project-discovery or issue-list traversal; hitting the limit fails visibly and retains the cursor, so increase it (maximum 10,000) or narrow the selection for very large installations. Initial imports and reconciliation can be expensive: each issue needs a detail request, and large journals also incur artifact and deduplication work. A project permission failure is reported without advancing its cursor while other projects complete; HTTP 429 and transient failures retain the cursor and are retried on the next scheduled run, with no rapid retry loop. Only one run per Redmine URL is allowed at a time.

• fields["project.identifier"], fields["project.id"], fields["project.name"]
• fields["issue.id"], fields["issue.subject"]
• fields["issue.status.name"], fields["issue.tracker.name"]
• fields["issue.priority.name"], fields["issue.assigned_to.name"]
• fields["issue.custom_field.12"] (actual Redmine custom-field ID)
• fields["journal.notes"], fields["journal.private_notes"]
• fields["change.attr.status_id.changed"] equals true
• fields["change.attr.status_id.new_value"] equals your resolved status ID

For field-only journals use issue.updated. To include both comments and changes, leave action empty and require the relevant change.*.changed field. Keen's structured fields are ANDed, and status IDs do not have identical meanings across installations.

issue.* is the issue state at capture time, including on historical journal events; the journal's details / change.* fields describe its historical change, so inspect them when mapping a historical transition. Historical comments imported in one scan may share the current issue status, which is not the status at the time each comment was written.

Events retain collection provenance and a link back to the Redmine issue or journal. They use the standard Keen redaction, artifact storage, SHA-256 and framework-rule pipeline, including S3 or immutable retention when configured. Stable content identities suppress repeated unchanged records; edited records produce new evidence versions and earlier artifacts remain. Switching collection selectors does not rewrite old provenance, so use structured project fields to map historical events across such a change.