Zombie tabs

Some more digging and debugging later, I add the following in an onLoad action on the offending form:

console.log("Am I dirty? " + aras.isDirtyEx(document.item));
console.log("Dirty according to direct check? " + ArasModules.item.isDirty(document.itemType, document.itemID));
console.log("Am I in an edit state? " + aras.isEditStateEx(document.item));
console.log("Edit state according to direct check " + ArasModules.item.isEditState(document.itemType, document.itemID));

Am I dirty? false
Dirty according to direct check? false
Am I in an edit state? false
Edit state according to direct check false

Am I dirty? true
Dirty according to direct check? false
Am I in an edit state? true
Edit state according to direct check false

Hi Harald,

I am familiar with the error and confirm that it can happen due to dirty items. For example the use case described in this post can super easily create dirty items by editing a part outside regular change control:  RE: non-revisioned properties or xProperties on an item 

But as far as I understand you just have regular relationship. 

Some question:

- Does the same error appear on other similar relationship tabs (like Part BOM, or Part Costs)?
- Do you use a regular relationship or NULL relationship?
- Do you use additional JS Methods like Form "onLoad" or RelationsihpType "onInsertRow" that update a property automatically?

I am not 100% sure where else in the system it appears. The custom Delivery Risk ItemType is a null relationship.

I found out the reason for the most confusing item logging above: when I properly use the ItemTypeID instead of document.itemType in the ArasModules.item calls above, it at least gave me consistent result with the isDirtyEx / isEditStateEx methods on the aras object.

I create the new Delivery Risk item in one method, and pass it to a modal dialog where the user can fill out the details and hit save. When they hit save, it then just .apply()-s the item I passed in. That is enough to create the item, but apparently not to make the frontend believe that it was created. My attempts to tell it in that function have all failed, however, I have worked around it by adding an onLoad function on the view/edit form, which checks if the item is dirty and saves it if it is. I still would very much like to know the right way to do it/prevent dirty objects from being created in the first place.

It makes sense that the behavior appears in the context of a dialog. This is very similar to the post I mentioned before. 

In the shown use case dirty items aren´t a big problem as the dialog is mainly executed from released items. In my case I reset the "isDirty" attribute to 0 inside the dialog callback function. This is important when user close the dialog without doing anything. Things get more complicated for item that can still be edited.

Quote: "checks if the item is dirty and saves it if it is" 

That´s one approach that I also use sometimes! You can even execute the save action automatically in silent mode to avoid to distract the user. As alternative, you can of course just tell the user to save first by themselves. This is an actual code sample that I use when I don´t want use the silent mode. Use case is an automatically sort_order renumbering function that user can use while working with the relationships:

// Don´t renumber if item is dirty (=unsaved changes)
const isDirty = window.aras.isDirtyEx(contextItem.node);
if (isDirty)
{
  return aras.AlertError("Blablabla please save first....");
}

I am not sure if this is the official recommended way to deal with dirty items. But I have seen similar solutions in the OOTB Innovator code.