Need to turn off auto populate of work_start and work_end in change management

TiffanyL
Tera Contributor

I am wondering how the autopopulate of work_start and work_end are configured. The business has requested that these items NOT autopopulate as they do not typically occur at the time of change and are completed instead at the time of review. Filling the field leads to incorrect times; we would prefer the end user be required to fill out both.

The system current works where:
Close phase = implement, then date/time stamped in actual start date
Close phase = review, then date/time stamped in actual end date

Where I run debug shows that the actual start/end date validation BR is being skipped? Can anyone tell me how this is coded and where I would start by turning this feature off?

1 ACCEPTED SOLUTION

sachin_namjoshi
Kilo Patron
Kilo Patron

The Work start date and Work end date are set by functions in Change Request State Model script includes. When state changes to Implement the Actual start date is populated, when state changes to Review the Actual end date is populated. This logic is scripted in the following script includes:

  • ChangeRequestStateModelSNC_standard
  • ChangeRequestStateModelSNC_normal
  • ChangeRequestStateModelSNC_emergency

As those are SNC script includes they are read-only and can not be changed, but all of them has secondary versions (they extend the SNC ones) that should be used if someone wants to overwrite the OOTB behaviour, those script includes do not have the SNC in the name: 

  • ChangeRequestStateModel_standard
  • ChangeRequestStateModel_normal
  • ChangeRequestStateModel_emergency

So you can write your own logic in the ones that extands the SNC scripts.

 

Just add to them those lines:

toImplement_moving: function() {
// comment, delete or change lines that fills the Actual start date
        //if (this._gr.work_start.nil())
            //this._gr.work_start = new GlideDateTime();
        return true;
    },

toReview_moving: function() {
// comment, delete or change lines that fills the Actual end date
        //if (this._gr.work_end.nil())
            //this._gr.work_end = new GlideDateTime();

        return true;
    },

View solution in original post

5 REPLIES 5

sachin_namjoshi
Kilo Patron
Kilo Patron

The Work start date and Work end date are set by functions in Change Request State Model script includes. When state changes to Implement the Actual start date is populated, when state changes to Review the Actual end date is populated. This logic is scripted in the following script includes:

  • ChangeRequestStateModelSNC_standard
  • ChangeRequestStateModelSNC_normal
  • ChangeRequestStateModelSNC_emergency

As those are SNC script includes they are read-only and can not be changed, but all of them has secondary versions (they extend the SNC ones) that should be used if someone wants to overwrite the OOTB behaviour, those script includes do not have the SNC in the name: 

  • ChangeRequestStateModel_standard
  • ChangeRequestStateModel_normal
  • ChangeRequestStateModel_emergency

So you can write your own logic in the ones that extands the SNC scripts.

 

Just add to them those lines:

toImplement_moving: function() {
// comment, delete or change lines that fills the Actual start date
        //if (this._gr.work_start.nil())
            //this._gr.work_start = new GlideDateTime();
        return true;
    },

toReview_moving: function() {
// comment, delete or change lines that fills the Actual end date
        //if (this._gr.work_end.nil())
            //this._gr.work_end = new GlideDateTime();

        return true;
    },

find_real_file.png

Since the snc script include is read only, will it work if we comment line no 32 in  ChangeRequestStateModel_standard

Bu these lines are now not present in any of the following:

  • ChangeRequestStateModel_standard
  • ChangeRequestStateModel_normal
  • ChangeRequestStateModel_emergency
    Is there any other way to restrict the autopopulating of actual start/end date?
  •  

Did you ever figure this out??  Also having the same issue.