You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Found while working #289 (plan, out of scope). Since #289, MSPDI keeps an assignment Baseline's BCWS/BCWP. The MPP importer (mppread) builds no assignment baselines at all: nothing outside projcore/src/mspdi.rs and the editor calls set_baseline_slot or constructs AssignmentBaseline. So opening an .mpp loses assignment baseline dates, work, cost and earned value, and a save to MSPDI/.yppx cannot carry them.
Fix: read assignment baseline fields (Baseline..Baseline10 Start/Finish/Work/Cost/BCWS/BCWP) from the MPP assignment var data into Assignment::baselines. Test: an .mpp corpus file with a baselined assignment, whose MSPDI export includes the <Baseline> block.
The merged fix (#507, fa53f74) fails on the real .mpp corpus. CI cannot see this: the corpus is private and not fetched in CI, so these tests only run where corpus/tools/fetch-mpp-corpus.* has been run.
On Windows, main 3834fb4, corpus yeroo/mpp-corpus b02a8e0:
cargo test --release -p mppread --test oracle_corpus
test assignment_oracles ... ok
test project_2024_oracles ... FAILED
panicked at mppread\tests\oracle_corpus.rs:486:29:
...\corpus/mpp/snapshots\44-baseline.mpp: decoded import: cannot read the assignments of this .mpp (invalid baseline work for assignment UID 17)
The error comes from mppread/src/assndecode.rs:106 ("invalid baseline {what} length …"), so project_from_mpp now refuses the whole file rather than importing it without that baseline. project_2024_oracles stops at this first failure, so later snapshots are not reached.
Separately, on a Mac with the same corpus, the same test file reported a resource count of 0 for 31-calendar-hours.mpp where the XML oracle has 1 (other 82 checks passing). Not reproduced here yet because of the failure above.
Correction to my comment above: the 31-calendar-hours.mpp failure is not in oracle_corpus.rs and is not hidden behind the 44-baseline failure. It is the library unit test overalloc::tests::project_assignment_and_resource_offsets (mppread/src/overalloc.rs:415), and it reproduces on Windows as well as macOS with cargo test --release -p mppread --lib. Running cargo test -p mppread --release --no-fail-fast -- --include-ignored shows three failures with two causes; they are now tracked separately: #517 (44-baseline, from #507) and #518 (31-calendar-hours).
Activity
yeroo commentedon Sep 28, 2026
Triaged priority:P0 (blocks current work).
Fix r5: refuse assignments on blank rows; scope the MPXJ calendar-bit…
Use as_chunks for resource name units (#445 ci)
Allow too_many_arguments on the oracle task-field checker (#445 ci)
Merge pull request #507 from yeroo/issue-445-mpp-import-builds-no-ass…
yeroo commentedon Sep 28, 2026
The merged fix (#507, fa53f74) fails on the real
.mppcorpus. CI cannot see this: the corpus is private and not fetched in CI, so these tests only run wherecorpus/tools/fetch-mpp-corpus.*has been run.On Windows, main 3834fb4, corpus
yeroo/mpp-corpusb02a8e0:The error comes from
mppread/src/assndecode.rs:106("invalid baseline {what} length …"), soproject_from_mppnow refuses the whole file rather than importing it without that baseline.project_2024_oraclesstops at this first failure, so later snapshots are not reached.Separately, on a Mac with the same corpus, the same test file reported a resource count of 0 for
31-calendar-hours.mppwhere the XML oracle has 1 (other 82 checks passing). Not reproduced here yet because of the failure above.yeroo commentedon Sep 28, 2026
Correction to my comment above: the
31-calendar-hours.mppfailure is not inoracle_corpus.rsand is not hidden behind the 44-baseline failure. It is the library unit testoveralloc::tests::project_assignment_and_resource_offsets(mppread/src/overalloc.rs:415), and it reproduces on Windows as well as macOS withcargo test --release -p mppread --lib. Runningcargo test -p mppread --release --no-fail-fast -- --include-ignoredshows three failures with two causes; they are now tracked separately: #517 (44-baseline, from #507) and #518 (31-calendar-hours).