Part Rev Defaults to First Rev

Our engineers noticed a change that happened over the weekend. In Part Entry > Revision Detail, the rev defaults to the first rev in the list. When you choose another rev, then go to checkout, it changes your selection to the first rev in the list. If you forget to check it, you can start checking out or editing the wrong rev.

This is also true if you try to make changes to the fields at the Revision Detail level in Part Entry. If you choose a rev (not the first) then click in Revision Comments to make a change, then save, the comments are updated on the correct rev, then the screen refreshes and defaults back to the first rev again.

This is new behavior since this weekend and we want the old functionality back. When we choose a rev, it should keep that rev selected when we check it out or make a change. It should not keep reverting back to the first rev in the list.

I think this is a bug, but before I waste my time documenting for a support group that will never read it, I figured I’d check in with the community. Any one else seeing this behavior?

Here’s a demo showing the weird behavior:

Confirmed, no idea when it started.

Yes we are seeing this as well. Just came here to see if anyone else is having this issue.

And this issue popping up after the .16 update?

We are on 2025.2.16. It was not an issue last week. Its started yesterday (Monday 4/13).

EDIT: I just submitted a support ticket…
Fire Burn GIF

.16 has been pretty rough. Yikes. :dumpster_fire:

Support says they can reproduce it in .16, and confirmed it was not an issue in .1. They also told me that there is not PRB on file for this, so she can’t tell if a patch will help. But if I want I can go try the CMP and update some patches to see if that would work.

:face_with_symbols_on_mouth:

Seriously? They basically just said that maybe a fix will work if you figure it out yourself.

I thanked them for confirming the issue was on their side, and for confirming they are working on it. I asked them to update me once they have the fix in place, as testing their potential fixes is not our responsibility.

Where’s that flaming dumpster icon when you need it?

Im Fine All Good GIF by Pudgy Memez

Everything Is Fine Burn GIF

2 Likes

Looks like in AfterUpdate event they added a condition > event-next > Refresh.

Overrided and disable in a layer the problem goes away.

I just changed this from false to true and the prob went away. :man_shrugging:

Safe Harbor: this is just a quick compare to an old version so could be wrong but this refresh is added recently is all I can say.

To be fair, support was pretty good on this. They accepted my first submission including the video and told me they could replicate the issue on their end. Great Job!

Support suggests that the issue will no longer be a problem in the next release. So by June this issue should go away. I’m going to try to force them to keep the ticket open until then. :wink:

did you get a PRB?

I always keep cases from closing when they go PRB. If there were any reliable status updates or suggested workarounds, etc on the PRB side I’d reconsider but find some front-line support personel provide periodic updates. We have no way to track open issues otherwise.

No… :thinking: