ECO Item in Browser changes after voting it from Planning and to In Work

Update on the issue.

If I close down my broser after creating the ECO and before voting the ECO to "In Work", the issue is not observed. Why this has an impact I have no clue at.

Bernt Ove

Update on the issue.

If I close down my broser after creating the ECO and before voting the ECO to "In Work", the issue is not observed. Why this has an impact I have no clue at.

Bernt Ove

Hi,

everybody loves ECO questions! People look at these questions and then they are happy that their own topics are much more trivial :). 

I am familiar with the EHT. Are there any additional custom modifications? In your ECO, do you only change the "state" of an item or also the "production state"?

First I would unhide the "Affected Items" tab so you can see it in the ECO. Check if the affected_id items and new_item_id items are correctly assigned. 

Hi Angelalp,

thanks for taking interest in this case, and yes ECO issues ara a special breed of problems :)

We can also change the production state in our ECO. Basically its the standart EHT version where we have defined our own production states and we have some additional state or validation function into the standard validation routines.

The functionality is working correctly on our live V12SP12 production environment, but the issue we see occurs both on our new test environment and our new production environment that is not yet gone live.

I unhided the affected items and the affected_id and new_item_id are correctly assigned. 

Its almost like the browser gets confused which item it should show in the form accordian. The signoffs tab is still linked to the Express ECO and thus we are able to vote the ECO though is workflow, but everything in the main item toolbar is now connected to the part that is the affected item.

If we now close the ECO and open it again, it shows correctly the data.

Hi,

if its a breakthrough or not I`m not sure, but we found a connection between when the issue is generated and if the part that is the eco`s affected part is open in a tab. 

By just cloing the part before going to the ECO and voting it to "In Work" we avoid the issue from being generated.

If we have a different part than included as a affected_item on the ECO it does not generate the issue, only if it is an afffected_item.

We also use custom production states, but I never found the patience to update the validation checks. Nevertheless, I have so far not seen this behavior at all.  

Can you reproduce the error in a OOTB I31 instance with the original ECO? 

As you mentioned 12SP12 I first thought the issue would be related to the "Inferno" grid changes. Aras introduced a faster grid engine back then around this version number (as far as I remember).

Your latest post indicates that the context item used for your affected part is invalid. Just like it would be if you execute a certain Method from an Item vs. the Method editor. "This" is something completely different depended from the context the Method is executed. 

Have you asked Aras about this one? 

We tried asking Aras support, but they want it to be handled as part of our upgrade process. I just don't understand how the "pre-" method in a life cycle transition can accidentally change what the context object is... in the frontend at that. 

It's also confusing how it still manages to do the right thing as long as there's no tab open with an affected part.

I thought you were currently in an upgrade process, that´s why I asked. As somebody who also uses EHT on a I12 instance, I am personally interested in this use case and will give it a try this week. 

Just to sum things up. The main problem is the corrupted keyed_name in the tabs? But it only appears when your Part is opened while voting? 

Is the corrupted keyed_name only visible in the tab labels? In late I12 and early I14 there were some issues with the tabs that occur when previous item versioned were opened while the current version was edited (Warning: Versioning and tab pane very buggy in new Innovator versions!!! Are you affected? ). But it was luckily fixed with I23.  But as ECOs also produce new items versions, this one could be an after effect of this behavior and maybe related.

I wonder if the same behavior exists in a blank OOTB instance?

Well, the corrupted keyed_name is a symptom. It more generally breaks the UI since it's supposed to have an ECO, and now has a Part (everything except the signoffs tab, curiously). It's also easy to get a zombie tab as a result of this. The problem is "just" UI corruption, but we really don't want to have to explain to all of our users the hoops they need to jump through to avoid the issue.
And yes, it only appears

* If the part is open when voting (but this happens often, since you often created the EHT from that part)
* On the transition from "In Planning" to "In Work".
* Only if the -pre method on that transition runs (EHT_PE_ChangeItemTransition)

EHT_PE_ChangeItemTransition is a monster of a function, which insists on implementing the logic flow through interfaces and dynamic dispatch in 4600+ lines. But I cannot see anything in there which should confuse the frontend about what the "this" object is.

Yes, customizing EHT_PE_ChangeItemTransition is like the end boss. 

Does the issue only appear if you create new revisions via the ECO? I assume you don´t get the described behavior if you only use the ECO for simple "Release" tasks. 

I made a quick test on a OOTB Innovator with PE_ChangeItemTransition in I23 but there wasn´t anything strange happening. I don´t have access to I30+ this week.

"In Planning" to "In Work" creates the new item revisions. Aras definitely had some challenges with tabs in I14, especially for versioned items. But I somehow expected these issues to be solved. 

Questions:

- Is the EHT version you use an official built for I31? Or do you use the exact same version you used for I12?
- If yes, compare the originial PE_ChangeItemTransition from 12SP12 to the version used in I31. They definitely will have changed a few functions related to .NET Core. 

Correct, we don't get the problem for simple "Release" tasks.

Yes, I think the issue is that since a new revision of the item is created, and it realizes it has that item open in a tab, it tries to update that tab - but sets the new itemid on the wrong tab for some reason. I'm trying to figure out where in the code exactly that happens.

About your questions, we've compared them but didn't find any obvious differences that should matter.