Change Management - Revert Normal Changed from Scheduled or Implement back to New

Mark Lanning · ‎12-02-2020

Discovered Cases where there is a need to Revert a Normal Change that failed to be executed and the State is Scheduled or even Implement, and the desire is to allow Support to Reset / Revert the Change back to New so it can be Rescheduled and go thru the Approval Process again.

Would like to come up with something like Revert to New that works when Change is in Assess.

Is there a Way to use UI Action when the Change Record is in Scheduled or Implement State to Revert to New.

Where when the Change Request was unable to be completed due to Issues and a Back Out Plan occurred the Change Request does not have to be Cancelled.

Kieran Anson · ‎12-03-2020

Hi Mark,

If you want to maintain the state model, this can be done by modifying the following:

Modify ChangeRequestStateModel_normal script include and add the following code segment under the states you wish to allow moving back to draft:

draft: {
            moving: function() {
                return this.toDraft_moving();
            },

            canMove: function() {
                return this.toDraft_canMove();
            }
        },

As an example, the code for "scheduled" now looks like:

scheduled: {
        nextState: [ "implement" ],
		
		
		draft: {
            moving: function() {
                return this.toDraft_moving();
            },

            canMove: function() {
                return this.toDraft_canMove();
            }
        },

        implement: {
            moving: function() {
                return this.toImplement_moving();
            },
            canMove: function() {
                return this.toImplement_canMove();
            }
        },

        canceled: {
            moving: function() {
                return this.toCanceled_moving();
            },

            canMove: function() {
                return this.toCanceled_canMove();
            }
        }
    },

Update the UI Action "Revert to New" so the condition looks like:

gs.hasRole("itil,sn_change_write") && ((current.type == ChangeRequest.EMERGENCY && new ChangeRequest(current).isAuthorize()) || (current.type == ChangeRequest.NORMAL && (new ChangeRequest(current).isAssess() || new ChangeRequest(current).isImplement() || new ChangeRequest(current).isScheduled())))

You'll likely need to move the condition into its own script include due to the length or change the max length attribute field to accept more than 254 characters.

View solution in original post

Sudeepta Jana · ‎05-03-2023

exactly I did this, it worked. Did not know that Solution was here in the community.

Dariussiriuse · ‎05-26-2023

For some reason, this doesn't work for me... I've added a condition on the UI Action as "gs.hasRole("itil,sn_change_write") && (new ChangeRequest(current).isAssess() || new ChangeRequest(current).isAuthorize() || new ChangeRequest(current).isScheduled() || new ChangeRequest(current).isImplement())" that being because I want this to work on ALL kinds of requests. The condition works fine as I get the button to appear at the desired states.

So, I've continued and added the bits of draft state as explained above to all three "ChangeRequestStateModel_..." (emergency, normal and standard to the desired place); but still gives me the "State Model for emergency/normal/standard changes does not allow reverting change from X state" error message.

Have I missed anything????

Best regards,

Darius

Sudeepta Jana · ‎08-01-2023

Hi Dariussiriuse,

Create a script include named as 'Change_RevertToNew'. Add the following code with a function show_reverttonew being called.

var Change_RevertToNew = Class.create();
Change_RevertToNew.prototype = {
    initialize: function() {},
    show_reverttonew: function(current) {
        var isstate = false;
        if (current.type == ChangeRequest.EMERGENCY && (new ChangeRequest(current).isScheduled() || new ChangeRequest(current).isAssess() || new ChangeRequest(current).isAuthorize()))
            isstate = true;

        if (current.type == ChangeRequest.NORMAL && (new ChangeRequest(current).isScheduled() || new ChangeRequest(current).isAssess() || new ChangeRequest(current).isAuthorize()))
            isstate = true;

        if (current.type == ChangeRequest.STANDARD && (new ChangeRequest(current).isScheduled()))
            isstate = true;


        return isstate;
    },
    type: 'Change_RevertToNew'
};

update the condition in the UI action like this

gs.hasRole("itil,sn_change_write") && new Change_RevertToNew().show_reverttonew(current)

It will work for sure.

StacyLen · 3 weeks ago

Hi all. I am on Yokohoma I've read and implemented much of the above. I was successful in getting a Normal Change in Scheduled state to RevertToNew. However, when I then started treating this change as if it indeed, were a New change, some unacceptable behavior occurred.

All seemed well until the final Peer Review in the Authorize State. Once that was completed, the Change skipped the Scheduled and Implement States, going directly to Review, leaving the Tasks not closed.

In discussions with SN Tech Support, indications were that getting the Change to RevertToNew was a minor part of the overall customization required to make the RevertToNew actually work correctly. While the Change may display a new State value, the processing of the Change would in fact likely break further processing because expected values would not be found by the Flows that move the record through it's stages.

This seems to be the issue that caused my "RevertED To New" change to then skip Scheduled and Implement.

I am further concerned that resolving the above mentioned issues, may put our Change Implementation so far outside OOTB configuration, that SN might elect to not support our Change Implementation.

Anyone have any 'more recent' experience ideas about this Area, I'd sure like to hear them

Very Respectfully,

StacyLen

If anyone knows a surefire method