Level of Effort activities were skipped outright. They are now imported as
IfcTask with PredefinedType ATTENDANCE, the nearest thing IFC has to support
work that spans what it hangs off. Their dates stay derivable: the SS/FS and FF
predecessors P6 computes the span from are ordinary relationships and are
written out like any other. Skipping them also dropped 970 relationships that
happened to touch one.
User defined fields and activity codes now land as P6_UDF and
P6_ActivityCodes property sets. Separate sets because they are separate
concepts in P6, and not IfcClassificationReference for the codes because they
are orthogonal facets rather than a hierarchy. A code's description goes on
IfcProperty.Description so the short value and the readable one both survive.
UDF types come from the root declarations, since that is the only place the
data type is known, and are written sparsely.
Task times are now transcribed rather than recalculated. edit_task_time exists
to keep a schedule self-consistent while somebody edits it, so it snaps dates
off non-working days and derives durations across the calendar: reasonable for
an editor, wrong for a transcription where P6 has already run the critical path
and its answer is authoritative. On one 4,181 activity programme it moved 3,534
start dates and disagreed with P6's own duration on 3,206 activities. Actual
dates, early and late dates, float and completion are now carried too, none of
which were written before.
WBS children are created in P6's SequenceNumber order rather than document
order. IfcRelNests keeps an ordered list, so this is all it takes for a reader
to recover the breakdown as the planner arranged it, and sorting any other way
shows a programme nobody recognises.
Also: the project name was read without the namespace map, so every schedule
came out called "Unnamed".
Importing a Primavera P6 XML crashed with
`AttributeError: 'NoneType' object has no attribute 'text'` in
P62Ifc.parse_activity_xml, which read
activity.find("pr:CalendarObjectId").text unconditionally. CalendarObjectId
is optional on a P6 Activity; when omitted, the activity inherits the
project's ActivityDefaultCalendarObjectId.
Capture the project default in parse_xml and fall back to it when an
activity has no CalendarObjectId (`calendar_id or self.default_calendar_id`).
Verified on the reporter's attached file (20241021 Cronograma.xml): 3 of 14
activities lack a CalendarObjectId and reproduced the exact crash on
v0.8.0; after the fix parse_xml completes and those activities resolve to
the project default calendar "2" (a valid calendar in the file). An
activity with an explicit CalendarObjectId keeps its own value.
Fixes the P6 re-import crash reported in #5617 (that issue tracks several
Gantt items; this addresses the import AttributeError).
Generated with the assistance of an AI coding tool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 694a44e638)
Now we're going to use bar ids instead their detalization ids (e.g. expanded task ids, task ids, milestone ids) because it is the way how it works in the software pp file originates from.
Please correct me if I am wrong:
while trying to create relationships I saw that in def create_rel_sequence (line 194) there is a parameter missing which should reflect the "rel_type", otherwise and according to "assign_sequence.py" the sequence_type remains
def assign_sequence(
file: ifcopenshell.file,
relating_process: ifcopenshell.entity_instance,
related_process: ifcopenshell.entity_instance,
sequence_type: str = "FINISH_START",
Andrej730
