BigPicture — Bulk Start/End Dates Shifted ~60 Years Into the Past

Executive Summary

Jira issue Start Date and End Date values were updated in bulk and appeared to shift approximately 60 years into the past. The changes were visible in issue history as being performed by an anonymous user, which made the origin of the updates initially unclear. The pattern indicated automated propagation rather than individual manual edits.

Background and Context

The Jira instance used BigPicture for planning and scheduling. BigPicture programs can apply scheduling rules and synchronize date fields back to Jira issues. When program-level scheduling is enabled, date values may be recalculated and written to issues based on program configuration and scheduling engine behavior.

What Was Observed (Symptoms)

• Start Date and End Date fields on multiple Jira issues changed.

• The resulting values were far in the past (reported as ~60 years earlier than expected).

• Jira change history showed the updates as performed by an anonymous actor.

• The behavior appeared as a bulk propagation across many issues, not isolated edits.

Expected Behavior

• Start Date and End Date should remain aligned with the plan and change only when:

• you edit them directly, or

• an integration/app updates them according to defined scheduling rules.

Automated updates should produce valid, realistic dates and should not shift issues into implausible historical ranges.

Investigation Summary

• Distinguishing whether changes were driven by a human user, a system integration, or an app workflow.

• Verifying whether BigPicture scheduling could recalculate and write dates back to Jira.

• Assessing whether the anonymous attribution was consistent with system/app-originated updates rather than a normal end-user session.

The bulk nature of the edits and their alignment with scheduling behavior indicated program-level scheduling propagation rather than manual updates.

Root Cause

The behavior was traced to a misconfigured BigPicture program (referenced as PROG-910 in the investigation context). With that configuration in place, BigPicture scheduling propagated incorrect date values to Jira issues, resulting in Start/End Dates being written as dates roughly 60 years in the past. The anonymous user attribution was consistent with an automated/system-level update path used by an app or integration context.

Resolution

The issue was resolved by correcting the BigPicture program configuration so that scheduling calculations no longer produced and propagated incorrect date values. After the configuration change, subsequent scheduling activity no longer resulted in the historical date shift behavior.

Scope and Impact

• Scope: Multiple Jira issues associated with the affected BigPicture program experienced Start/End Date changes.

• Impact type: Planning and reporting disruption due to incorrect schedule dates and distorted timeline views.

• Visibility: High, because these fields are commonly used in plans, reports, and timeline views.

Contributing Factors and Risk Areas

• Program-level scheduling rules that write back to Jira without guardrails.

• Field mapping that allowed Start/End Date overwrites from BigPicture to Jira.

• Lack of constraints or validation preventing unrealistic historical dates.

• Anonymous/system context used by the app, making accountability and traceability harder.

Verification Steps Used

1. Reviewed issue histories to confirm actor, timing, and field changes.

2. Checked BigPicture program configuration (scheduling mode, calendars, field mappings, sync options).

3. Correlated timestamps of bulk changes with program scheduling jobs/runs.

4. Temporarily disabled write-back to Jira to stop propagation and confirm source.

5. Reproduced behavior in a safe test project to validate the misconfiguration effect.

Preventive Actions and Hardening

• Implement validation rules or automation to reject Start/End Dates that fall outside a reasonable range (for example, more than 10 years in the past or future).

• Restrict app write-back permissions to controlled service accounts with explicit logging.

• Enable audit logging and dashboards to detect bulk historical date changes in near real time.

• Standardize BigPicture program templates with reviewed field mappings and scheduling settings.

• Require change review for any modification to program-level scheduling rules.

Operational Runbook (Quick Triage)

Forensics Checklist

• Jira issue history export for a sample set (actor, field, old/new values).

• App logs/audit logs for BigPicture scheduling jobs at change timestamps.

• Configuration snapshot of program PROG-910 (before and after fix).

• Field configuration and context for Start/End Date custom fields.

• Service account details used by BigPicture and permission scopes.

Recovery Options

• Use Jira bulk edit to restore dates from a CSV sourced from backups or history reports.

• If available, use BigPicture restore/export to correct dates in the program and re-sync to Jira after validation.

• Implement a temporary automation rule to block or flag dates older than a threshold until stability is confirmed.

Appendix: Likely Misconfigurations to Review

• Start/End Date mapping direction set to bidirectional or program-to-Jira without constraints.

• Calendar/timezone offsets or epoch-like defaults producing extreme dates.

• Roll-up rules or dependency constraints causing negative durations and retro-propagation.

• Incorrect baseline use or alignment to a reference date far in the past.

FAQ