I appears that when we enter the Reports tab, the child-relationship module is loading up the children and setting the parent reference onto each child. Then when the ticket item is removed (Ticket.prototype.handleTicketItemRemovedFromTicket in ticket/index.js - line 203) it’s doing the scorched earth disposal which is in turn disposing (hollowing out) of the newly added parent Ticket object.
The problem here is two fold:
During the setup of the PrintDataContext, we load up the TIckets children (i.e. ticket items, etc) and set those on the Ticket object.
We also set a reference to the Ticket on each of the ticket items.
So when we remove a ticket item, during the disposal process, we hollow out the Ticket object. This causes problems because the Ticket object is still being used by other contexts (i.e. we’re still in the details of the Ticket).
We are also hollowing out the ticket item object yet we still have a reference to it in the Ticket objects FX5__Ticket_Items__r collection that has not been removed. This is what causes the Report tab to break after going back to the reports tab after deleting an item.
I toyed with some ideas about how to avoid hollowing out the Ticket object off of the ticket item(s) and determined that the correct approach is to have the PrintDataContext and ChildRelationship object properly clean up after themselves. This will involve:
Adding a “dispose” method to child-relationship.js
need to track each parent relationship added to the loaded children.
Adding a “dispose” method to print-data-context.js
need to track each child relationship object in order to call dispose.
adding an instance variable to the PrintDataContext instance so that it will be disposed of on “deactivate” in ticket/report/new.js
probably also need one for eforms (and now jobs) – is there a way to extract/encapsulate this? Probably not as the PrintDataContext is just a viewmodel and not a “view” module that get deactivated, so it needs to be deactivated manually by whoever uses it.
Doing the above should correctly/appropriately allow the removal of any report-only objects, added solely for the purpose of reporting, when the report modal is deactivated.
githubbob42
commented
9 years ago
Mingle Card: 3656 Analysis
I appears that when we enter the Reports tab, the child-relationship module is loading up the children and setting the parent reference onto each child. Then when the ticket item is removed (Ticket.prototype.handleTicketItemRemovedFromTicket in ticket/index.js - line 203) it’s doing the scorched earth disposal which is in turn disposing (hollowing out) of the newly added parent Ticket object.
The problem here is two fold:
So when we remove a ticket item, during the disposal process, we hollow out the Ticket object. This causes problems because the Ticket object is still being used by other contexts (i.e. we’re still in the details of the Ticket).
We are also hollowing out the ticket item object yet we still have a reference to it in the Ticket objects FX5__Ticket_Items__r collection that has not been removed. This is what causes the Report tab to break after going back to the reports tab after deleting an item.
I toyed with some ideas about how to avoid hollowing out the Ticket object off of the ticket item(s) and determined that the correct approach is to have the PrintDataContext and ChildRelationship object properly clean up after themselves. This will involve:
Doing the above should correctly/appropriately allow the removal of any report-only objects, added solely for the purpose of reporting, when the report modal is deactivated.
UPDATE:
There are a number of factors going here.
Steps to reproduce
Alternate path: replace steps 8, 9, 10 with
Expected result
What should happen?
Actual Result
What actually happens?
Related Cards
Test Plan
goto a ticket
add an item
goto reports tab, open report (no need to save – just close it)
go back to items delete item.
(two paths to test from here)
Checklist for Merging