joniles/mpxj

Orphan tasks when a wbs id equals a task's id

kirlev opened this issue · 5 comments

kirlev commented

Hi, version 12.0.1 introduced a change that as it says in the release notes:

Ensure that invalid duplicate Unique ID values encountered when reading schedule data are renumbered to maintain uniqueness.

This change causes an XER file exported from Primavera not to be parsed correctly, tasks that has wbs parents are parsed as though they do not have parents, the reason is that some of the tasks in the file has the same unique id as some of the wbs records, this in turn causes children tasks to not find there parents in the PrimaveraReader.

I think it is because the m_activityClashMap is used for both wbs records and tasks, can it be separated to 2 clash maps?

kirlev commented

Actually, in a closer inspection, this behavior was not introduced in 12.0.1, the m_activityClashMap and its methods looks to be older than that.

In any case, since it looks to be a valid scenario in the XER file to have a wbs id identical to a task id, how about having a clash map for each record type?

joniles commented

Hi, thanks for opening the issue. Would you be able to provide me with a sample file which illustrates the problem?

kirlev commented

Hi @joniles , thanks for the quick response.

Unfortunately I cannot share the file because it belongs to a user, but I did managed to reproduce the problem by editing a sample XER file, I attached the original and the altered files.

Notice that in the altered file you will not find taskId 105420, I changed it to 27330 which is an id of an existing wbs record.

The 2 files will have the same structure in P6 but will have different structure after being read by Mpxj, this is the same issue that we found in the file a user provided us.
sample xers.zip

joniles commented

Thanks for the sample file - I will look at this as soon as I can.

  • 👍1
joniles commented

I've applied a fix for this issue, the change will be available in the next MPXJ release.

  • 👍1