Content
View differences
Updated by Kabiru Mwenja 1 day ago
**Summary**
In the work packages API with `timestamps`, when the last requested timestamp is historic, the returned work package table, baseline comparison between two past dates shows today's today's observed-in versions instead of the versions the work package had at the second date. Every while every other column, attribute, including Target target versions, shows the state at comes from that date. point in time.
**Steps to reproduce**
1. A work Work package whose with a journal history in which the observed-in versions changed over time, changed, for example observed in "Baseline 1.0" three days ago, in "Baseline 1.0" "1.0" earlier and "Baseline 1.1" two days ago, and in "Baseline 1.0", "Baseline 1.1" and "Baseline 1.2" today (target version 1.0, then 1.1, then 1.2 at the same times).
"1.1" now.
2. Open `GET /api/v3/work_packages/<id>?timestamps=<timestamp before the project's work package table change>` (single historic timestamp, no `PT0S`).
3. Compare `_links.observedInVersions` of the element with the columns Target versions and Observed in versions.
3. Baseline, "Between two specific dates": first date three days ago, second date two days ago (both before today's change).
`_links.targetVersions`.
**Actual behavior**
Observed in `_links.observedInVersions` lists the current versions shows today's three values, "Baseline 1.0, Baseline 1.1, ..." with a count of 3, as ("1.1"). `_links.targetVersions` and the state at other attributes show the second date. Target historic state. The `attributesByTimestamp` entry for that timestamp lists the historic observed-in versions shows "Baseline 1.1" with "Baseline 1.0" struck through, which is the correct state at the second date. correctly.
**Expected behavior**
Observed in versions `_links.observedInVersions` on the element shows the observed-in versions as of the second date, "Baseline 1.0, Baseline 1.1", with the baseline value "Baseline 1.0" struck through, consistent with the Target requested timestamp, like target versions column. do.
**Environment**
dev branch, docker development stack, Chromium. branch.
**Screenshots **Additional context**
`API::V3::WorkPackages::EagerLoading::HistoricAttributes#override_attributes` copies scalar attributes and attachments**
baseline-between-dates-observed-in-wrong.png (the bug), baseline-yesterday-ok.png (baseline "since yesterday", where both columns are correct, for contrast). `target_versions` from the historic source (b3e8fc681a2, 2026-08-06) but not `observed_in_versions`, which the historic loader gained later in f9996e159cb (COMMS-977, 2026-09-04). Found while reviewing https://github.com/opf/openproject/pull/25320#discussion_r4337744769. Fix: one more `override_association` call plus a request spec example.
In the work
**Steps to reproduce**
1. A work
3. Compare `_links.observedInVersions` of the element
3. Baseline, "Between two specific dates": first date three days ago, second date two days ago (both before today's change).
Observed in
**Expected behavior**
Observed in versions
**Environment**
dev branch, docker development stack, Chromium.
**Screenshots
`API::V3::WorkPackages::EagerLoading::HistoricAttributes#override_attributes` copies scalar attributes
baseline-between-dates-observed-in-wrong.png (the bug), baseline-yesterday-ok.png (baseline "since yesterday", where both columns are correct, for contrast).