Getting This object has been modified, please refresh and try again error
I have a need go to prevent a workflow from being approved if there are mandatory attributes values missing from an ECO. I wrote a PX with the “Approve for Workflow” PRE event to advance the workflow (removed the auto-promote) with code. If it fails, I throw an exception to show the user the error. If all is well, the workflow would advance, and I was hoping it would move forward with the approval process. However, I was receiving a “This object has been modified, please refresh and try again error” error, preventing the approval to take place.
Below is the code, any help would be greatly appreciated.
// Disable all warning messages including one not all approval has been done
session.disableAllWarnings();
IStatus [] sts = null;
sts = workflow.getStates(StatusConstants.TYPE_REVIEW);
IStatus release = sts[1]; // This is the status I want to advance to
// TRY/CATCH block to retrieve more detailed message
try {
ECO.changeStatus(release, false, “”, true, true, null, null, null, false);
} catch (APIException ae) {
throw new Exception (“ERROR……);
Thank you everyone for your help. I will go forward with validation only in the PRE event and not advance the status.
Mmmm…I’m pretty sure you can’t mix those two in a single script. Regardless of whether or not the ECO had the mandatory attributes filled in or not, I’m very certain Agile would have bumped the object version up since Agile will log that your script ran to the history tab of that eco. Therefore, when you then try to update the state, Agile’s trying to work off of an older version of the same ECO.
You can prove this by adding int obj_versionX = eco.objectVersion() or adding Boolean up_to_date = eco.isUpToDate() checks to your script.
Try adding the line eco.refresh() before the session.disableAllWarning(); line and see if that works.
Nonetheless, I’ve read about bugs involved that make Agile throw the “This object has been modified” error, so if none the above tricks work for you, you may be facing something more complicated and will have to try different options like a POST event.
Besides, on a PRE event, when Agile runs the script before the action actually happens at the database level, Agile hasn’t actually added the last approver’s signature to the ECO officially, so any script to release or change status should fail (because Agile knows that the person hasn’t yet approved).
Matt is right about trying to do any modifications to the change in a pre-event. You can’t. The system does not refresh after calling the pre-event so it has an old copy of the ECO.
We have it currently to auto-promote. The issue we are having is that if there are missing values, the approval will be completed but the status will not advance. Since an error does not pop up telling the users that is a problem, they sometimes don’t realize that the status did not change. The history tab indicates the problem but that can be easily overlooked. This is the issue we are trying to solve. Any other suggestion would be appreciated.
The main alternative here that I can think of is a POST event. Upon ECO approval, and after your other PX has already blocked any signature from being registered when there’s missing fields on the ECO, write a different PX that will conduct a few checks (such as eco.audit(), missing fields, all-approve, etc.), then change the workflow. Turn off auto-promote and just let your PX do the heavy lifting. You can trigger this by ‘Approve for Workflow’ or even as a scheduled event w/ Query, among other options.
I empathize with you too – failed auto-promote messages don’t tell a user what was missing until someone goes in and manually tries to change the status.
Hi,
Why ain’t you using a pre subscriber to check the mandatory fields are filled in or not and accordingly throw the error, thereby stopping the auto promote of the ECO to the next status ? If the validation is successful then anyhow the Agile autopromote will automatically move it to next status. Do not explicitly use changeStatus() method from within the handler of your pre-subscriber.