Ran into a fun little “Epicor does what it wants” situation with data integrity controls, and I could use some extra brain horsepower (or maybe just a group therapy session).
Here’s the scoop:
My BPM is blocking direct PartPlant updates like a heroic bouncer at a sketchy nightclub. But Epicor’s sneaky “update all sites” button has apparently been taking ninja lessons—it slips right past my defenses and changes my frozen-in-carbonite site without so much as a knock.
I built a BPM that intercepts Part.Update and nukes any PartPlant record changes for the forbidden site. Works flawlessly… until the multi-site update feature shows up like a drunk uncle at Thanksgiving, ignores all house rules, and wrecks the living room.
So: has anyone figured out how to intercept/filter this bulk-update party crasher? I need my forbidden site locked down tighter than Fort Knox, while still letting Epicor spread its joy across the sites that are actually allowed to change. I’m guessing I need to hook into a different BO method or sneak in at the dataset level—but open to ideas, even if they sound like fever dreams.
Screenshots attached for your viewing pleasure (or horror).
Thanks in advance, fellow code wranglers! May your BPMs be swift and your trace logs merciful.
Yep, went down that rabbit hole too! Found where the In Transaction DD triggers and can see the exception point, but that’s exactly the problem - I don’t want to nuke the entire bulk update, just surgically block the one bad site.
Is there a clean way in the In Transaction DD to selectively revert just the protected site record without killing the whole transaction? Thinking something like reverting the ttPartPlant record back to original values for just that site while letting the other sites proceed normally?
The bulk update should complete successfully for all valid sites, but the bad site should stay frozen. Ideally the user never knows anything got blocked.
Anyone figured out a slick way to do this selective blocking at the DB level?
In the in-transaction dd, you should be able to use a linq query on Db.PartPlant to pull the original row before modification. overwrite the row in ttPartPlant with the original one from the database.
probably what is happening is that the bulk update doesnt actually use the part.update method (just guessing) and goes around it.
If you did it with a data directive, and put some magical C# code that would replace the new values with the old values just before it was written, it would probably resolve the problem.
