Bug
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].
|
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
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.