revolution icon indicating copy to clipboard operation
revolution copied to clipboard

UNINSTALL_OBJECT not working correctly in transport packages

Open BobRay opened this issue 1 year ago • 2 comments

Bug report

Summary

Correct me if I'm wrong, but the UNINSTALL_OBJECT constant was added to make the updateability and removal of objects independent. IOW,

  • Objects with UNINSTALL_OBJECT=true would always be removed
  • Objects with UNINSTALL_OBJECT=false would never be removed
  • Objects with UPDATE_OBJECT=true would always be updated
  • Objects with UPDATE_OBJECT=false would never be updated

Historically, this was controlled by UPDATE_OBJECT alone. If set to false, the object was not removed. I believe the addition of UNINSTALL_OBJECT was supposed to fix this.

This is not quite the case.

This combination works:

xPDOTransport::UNINSTALL_OBJECT =>false,
xPDOTransport::UPDATE_OBJECT => true,

The object is updated but not uninstalled.

This combination does not:

xPDOTransport::UNINSTALL_OBJECT =>true,
xPDOTransport::UPDATE_OBJECT => false,

The object is not updated, but is not uninstalled. It appears that UPDATE_OBJECT=false is still preventing the removal of the object.

My tests involved resources, with and without related objects.

BobRay avatar Apr 15 '24 20:04 BobRay

By the logic in the code, both have to be true in order to uninstall an object.

opengeek avatar Apr 15 '24 21:04 opengeek

Right, but why? I thought one of the points of UNINSTALL_OBJECT was for the case where you don't want an object updated, but do want it removed on uninstall. Most objects in an extra that shouldn't be updated should not hang around after the extra is uninstalled.

The two constants should each act on their own, as there is no reason for them to interact, IMO, and having them interact is limiting -- something we usually don't like to do in MODX.

BobRay avatar Apr 15 '24 23:04 BobRay