Module import fails because dobject is null

Developer comments

This is a rare situation where the package of the module has to be written, so that the new ids of the pieces are known, but not commited, since there might be a mapping error. During the mapping the reading of the services fails since a new service imported through the module does not have a dobject yet.

This is tricky. Long story cut short: it might be better to simply allow a module to be easily deleted rather than preventing the import because of mapping errors. The mapping error can be thought of as programming error which needs to be fixed after the import. This can be done quite easily by looking at the content of the module in the target store. So removing the option to ignore mapping errors and [14060, create a way to easily delete a module] will on the one hand make it superfluous to fix this issue and will create a "rounder" experience for the administrator.

This is less of a fix, more of a workaround.

This occurs in other situations as well. In this case Feiertag\_v3.zip was imported into a store using Feiertag\_v2 and the import failed despite showing a modal dialog with the message "Ok".

There is a [14071, bug in FastWriter].

Reporting date

2025-05-15

Reported by

Robert Cerny

Resolving date

2025-05-21

Resolved by

Robert Cerny

Resolved in version

Topincs 10.0.0

Related to

Mapping errors should always be ignored when importing a module(Change)

Caused by2

Missing dobjects should cause an exception(Change)

Dobjectification in FastWriter incomplete(Bug)

Work sessions3

Start	2025-05-16T08:49:44
End	2025-05-16T10:34:57
Participant	Robert Cerny

Start	2025-05-17T15:08:51
End	2025-05-17T16:37:54
Participant	Robert Cerny

Start	2025-05-21T10:26:35
End	2025-05-21T11:00:00
Participant	Robert Cerny