2012-09-17 Release

Summary

This release primarily involves:

  • modifications to the change module
  • social IT changes
  • ESS initial rollout

Change Control

CHG0003185

Release Notes

https://yale.service-now.com/kb_view.do?sysparm_article=KB0000066

Documentation

Detail is provided in the description. Full implementation detail is captured in the update set, which can be viewed (with admin rights) by drilling down into the links.

Requirements/Defects (Change)

Requirement (Original Names)

Functional Tested?

QA Tested?

Dev Status Notes

Description

376

(tick)

(tick) (w/ caveat)

(Vamshi) Works fine (However, the Change Type gets updated only after using ‘Execute Risk Calculation’)

When submitting the risk calculation clicking on the 'submit' button should calculate (and also re-calcualte when redoing the risk calculation) the risk assessment. Should not have to click on the 'execute risk calculation' to recalculate. Marked as a higher priority requirement by Change Process team.

423

(question)

(tick)

(Retest) w/ Charlie. This works & passed QA.

When the Change passes through the CAB and goes into implementation phase changes cannot be made to the Change in the system. ITIL users should be able to add work notes, comments and attachments to the Change but not make changes to any of the other fields.

536

(question)

(question)

missed documentation, just added to list... but was there originally. Implementation details changed from originally stated prescription.

Change: add new Change Task type of "Review"

  • this requirement as originally stated was looking for ad hoc approvals, which might have caused problems for Configuration/Change process in the future. Now people will be able to create/assign change tasks to have people review changes, but approval ultimately resides with the CI owner.

546

(error) 9/4

(tick)

(Charlie) If the Owner group is changed the change goes back to Acceptance state. If the change is in CAB approval State you can roll back to Acceptance State. After it gets to implementation state the ability is no longer there to go back.

Defect #311: Change: Change Manager needs the ability to roll changes back to any prior phase without breaking workflow. If Change goes back to prior phase it should then have to go through all appropriate approvals again as it moves through the workflow.

556

(tick)

(tick)

(Retest) Failed if 'Submit for Acceptance' UI Action used in a standard change. This button doesn't make sense in a standard change.

Change: Planned/Actual End dates should be after Planned/Actual start dates. Currently you can make a planned end date before the planned start date.

561

(tick)

(tick) 8/21

(Vamshi) Failed (Needs a tweak). (Bill) Modified this so that the UI action doesn't appear until the required fields are entered and saved.

Change: Risk Assessment Process. When filling out a risk assessment you should have to fill in the required fields BEFORE filling out the risk assessment so you don't fill out the assessment and then lose your info because you haven't saved. Currently if you fill out the risk assessment and you have not filed out the other required fields you can't save the change and you lose the work you did on the risk assessment. Need to make sure that when you fill in the data before filling out the risk assessment it does not disappear when the risk assessment is saved.

562

(tick)

(tick)

(Vamshi) Failed (Needs a tweak). (Bill) This was changed to be required in Assessment phase, along w/ planning info

Change: Planning information should not be required at the assessment phase as you do not know any of these until you're closer to Production time. This 'planning' information should be requried before the second approval (CAB or second Manager approval).

563

(tick)

(tick)

(Retest) Jumps to implementation during standard change, does not allow you to select for release (this checkbox will be hidden in standard changes, since per the Change Process they are preapproved).

Change: Second Approval RequirementsManager of Change Owner Unit: Approves Minor Changes Andrea (Release Manager): Must approve the Change if the 'Application Change for Release' box is checked.CAB: Must approve for major, signifiant or when the newly requested 'CAB Approval' box is checked. Dual Approvals: If the change is significant or a major change and the assessment code is application change for release then both the CAB and release manager need to approve.

564

(error) 9/4

(tick)

(Vamshi) Works fine (The checkbox is hidden for a Standard Change). But I think it would be apt to communicate about this change to Chloe and have her update the existing requirement in HPQC. (Charlie) Works O.K. but once the Change moves into CAB approval state the box can no longer be modified for any type change.
Standard Change – If box is checked for this it also works but no approval is required.

Change: Add a box that says 'CAB Approval Required'. If the change is major or significant the box is checked automatically. Changes that are mimor folks should be allowed to check this box. If thie box is checked then the change needs CAB approval. If this box is checked via automatic workflow (e.g if the box is checked because the change is significant or major) the box may not be unchecked. The box should only allowed to be unchecked if it was checked manually.

574

(tick)

(tick)

(Can't Replicate) was working but failed again on 8/21, need to replicate

Change: When Assignment Group Changes Approver should change. If a Change is mistakenly assigned to a group and then re-assigned to the right group the approval stays with the manager of the original group. The approval from the original group should no longer be required and approval from the new group manager should be required.

575

(tick)

(tick)

(Restest) per Charlie: Defect 363: closure code is req'd, but once you close PI task the change closes w/ a blank closure code

Change: Make Actual Implementation Dates and Implementation Code required before the Change can be moved to the post implementation phase. These fields need to be completed before the Implementation task can be completed and the change move to the Post Implementation phase. Added a check for closure code pursuant to this defect.

377

(tick)

(tick)

trivial

Hide Configuration Item on Change Task screen. Add 'Affected Component' to the Change Task screen. The data in the affected component should carry over from the parent change.

434

(tick)

(tick)

OK

Change: At the bottom of the Change ticket where it shows the approvals to be approved and the approval history it should tell me what type of approval is required or what type of approval was done.

518

(tick)

(tick)

OK

1- Add 'Create Standard Change' to the Change Module menu in the navigation screen
1a- When selecting this option it should do the same thing as applying the standard change template in the template field on the Change screen. Applying this special template not only fills fields but also applies the standard change workflow applied when this template is used.
2- Change 'Create New' to 'Create Normal Change' in the Change module menu in the navigation screen
3- Remove the Standard Change Template from the available template list
4- Remove the Template field in the Change ticket

535

(tick)

(tick)

This was changed to be required in Assessment phase, along w/ planning info

Change: Make Change Owner a required field before submitting for CAB approval. Per Lou Tiseo.

541

(tick)

(tick)

OK

The Post Implementation Task is requiring CAB review for every change. This Task should be completed by the Manager of the Change Owner Unit for minor changes. All Significant and Major Changes get PIR by CAB.Please change the default task to have the Change Owner Unit Manager Minor Changes. - Lou Tiseo

553

(tick)

(tick)

OK

Change: Would like to be able to select a highlight button for change type. Per Lou Tiseo.

565

(tick)

(tick)

OK

Change: Remove the Assessment Condition Codes drop down box and the fact that this is a required field.

573

(tick)

(tick)

OK

Change: Add a check box that says 'Application Change for Release' with accompanying workflow. If this box is checked the Change must have a parent change. If there is no parent change the Change should not be allowed to go to the CAB for approval. The Change should not be approved to go to implementation without a parent change (e.g. a release).

Requirements/Defects (Other)

Requirement (Original Names)

Functional Tested?

QA Tested?

Dev Status Notes

Description

642

in development

Social IT: Help Desk chat

  • create chat mgr group, add users pags, chloe, capuano, adriene, kovacs, seluga
  • link this group to the help desk chat
  • apply our 8-5 minus holiday schedule to help desk chat

RfR

(tick)

functional testing only

Request: add a service request that allows people to craft a SC entry & request. Full requirements documentation forthcoming in QC.

Approved Updates

Update Set (Original Names)________

Description

2012/09/17 - 3

Requirement 423 - change field accessibility redux (again)

  • explicitly make implementation codes required/mandatory in implementation phase – this did in some cases even though the UI policy was not present (???)

2012/09/17 - 2

Requirement 423 - change field accessibility redux (again)

  • remove implementation codes field from the list of read-only fields

2012/09/17 - 1

Requirement 575 - Change: make actual start/end dates mandatory prior to change closure.

  • improve error message that shows up in Change Task

2012/09/04 - 2

Requirement RfR - Social IT: set up help desk chat

  • create group CHAT_MGR (not captured), give chat_admin role
  • modify Social IT chat_admin left nav apps/modules (constrain attention to queue module)

2012/09/13 - 3

Requirement 376 - Change: automatic risk calculation

  • remove update capture field from form (reverse inadvertent change from previous update set)

2012/09/13 - 2

Requirement 561 - Change, planning fields should be required

  • since the UI policy is not working in some cases, adding a client script w/ duplicate functionality

2012/09/10 - 5

Requirement 564 - Change: CAB approval required field

  • change order of ui policy that hides fields during draft & standard change

2012/09/10 - 4

Requirement 564 - Change: CAB approval required field

  • hide this field when in draft phase, or if template is standard change
  • ensure the same is true for application change for release field

2012/09/10 - 3

Requirement 376 - Change: restore active status of Change Type business rule

  • change order of dependent business rules so they fire correctly
  • always recalc change type on updates
  • always run risk calc on updates

2012/08/31 - 5

Requirement 575 - Change: make actual start/end dates mandatory prior to change closure.

  • fix related Defect 363: closure code is req'd, but once you close PI task the change closes w/ a blank closure code; ensure you can't close PI task w/o a closure code
  • limit change states in which the risk calculation is run

2012/08/31 - 4

Requirement 563 - Change: Second Approval RequirementsManager of Change Owner Unit: Approves Minor Changes Andrea (Release Manager)

  • hide change for release toggle from standard changes, since no approvals need to apply to standard (i.e. preapproved) changes

2012/08/31 - 2

Requirement 376 - Force the Risk Assessment calculation

  • re-activate sc_task BR which checks for a risk assessment

2012/08/31 - 1

Requirement 376 - Force the Risk Assessment calculation

  • make a new risk calculator business rule that fires on updates, based on the UI Action

2012/08/30 - 2

Requirement RfR - FRU0011980 - Request: TBD now shows in the yale shopping cart.
Workflow set to 20 days.
-Sam

2012/08/30 - 3

Requirement 561 - Change: Risk Assessment should warn earlier about required fields

  • switch back to original requirement... planning info required at assessment phase, UI action script checks for presence of req'd fields.
  • add informational messages on how to advance change, when to fill out assessment, when to close assessment task.

2012/08/29 - 1

Requirement 376: Change: Currently, it has been reported that editing the Risk Assessment does not force an update of the risk assessment calculation, and that the user must initiate this via a UI Action.
The request is to make this calculation happen automatically any time the risk assessment is updated.

2012/08/29 - 4

Requirement RfR - FRU0011980 - Request: cart issue, jelly with ui macros, changed workflow to 14 days.
Changed UI macro but, unable to get another call to work for delivery time.
Ok to push, I'll create another Update set tomorrow.
Sam

2012/08/22 - 1

Requirement 376 - Change: risk assessment business rule

  • make risk assessment run automatically instead of via UI action

2012/08/29 - 3

Requirement RfR - FRU0011980 - Request: v7 update
inactivated all categories except for the 2 that contain items - Can We Help You and IT Service Management, then added the new categories. Filtered to see only active categories on form.
This can be pushed.
-Sam

2012/08/28 - 3

Requirement RfR - FRU0011980 - Request: change filter for group search to u_assignment is false (2 places)
done.

2012/08/28 - 1

Requirement 556 - Change: Planned/Actual End dates should be after Planned/Actual start dates. Currently you can make a planned end date before the planned start date.

  • fix so that "Submit for Acceptance" UI Action is not in a standard change, since it doesn't apply in this case.

2012/08/27 - 1

Requirement RfR - FRU0011980 - Request: All options have been corrected and the workflow approval should mark it as approved now.
13,14,15 are questions that will be addressed later.
List of categories - seeking confirmation.
Okay to push.

2012/08/23 - 1

Requirement 561 - Change: Risk Assessment should warn earlier about required fields

  • don't present risk assessment button until required fields are saved; otherwise it's still possible to fill in the fields (but not save) and then reproduce a similar conundrum this requirement is trying to solve.
  • provide hints to guide users through, since this essentially adds an extra (non-obvious) step.

CSI0015

CSIaaS: Change target url in itsmcoach ui page

2012/08/21 - 1

Requirement 423 - change field accessibility redux (x3)

  • add CAB Approval Required field to read-only list
  • remove device/asset field from change form. data preserved... still accessible from lists.

2012/08/20 - 2

Requirement 561 - Change: Risk Assessment should warn earlier about required fields

  • switch back to original requirement... planning info required at assessment phase, UI action script checks for presence of req'd fields.

2012/08/20 - 1

Requirement 423 - change field accessibility redux (again)

  • added change_advisory (requires manual group modification for CAB)
  • added many more more read-only fields to the client script
  • added condition to client script to also exempt change_advisory from the read-only rules

2012/08/17 - 1

Requirement 564 - Change: add a 'CAB Approval Required' boolean field

  • convert Data Policy 'CAB Approval Required' to UI Policy
  • add a business rule that sets this field to true under certain conditions

2012/08/16 - 1

Requirement 423 - change field accessibility redux; requirement changed:
When the Change passes through the CAB and goes into implementation phase changes cannot be made to the Change in the system. ITIL users should be able to add work notes, comments and attachments to the Change but not make changes to any of the other fields. Change Owners should have the same permissions here as the ITIL users. The Change Manager Role and anyone in the CAB assignment unit should be able to edit all fields (excluding system generated ones like Change number or Timestamp fields like Date Opened).

  • make read only: Dates, Change Source, Environment, Change Owner, IT Provider Service

2012/08/08 - 1

Requirement RfR - FRU0012350 - Request: RITM Stage - Approval Does Not Change in Workflow "New Service Request"

  • fix problem whereby RITM 'Stage' remains 'Waiting for Approval' after approval given.

2012/08/07 - 2

Requirement 423 - change field accessibility redux; requirement changed:
When the Change passes through the CAB and goes into implementation phase changes cannot be made to the Change in the system. ITIL users should be able to add work notes, comments and attachments to the Change but not make changes to any of the other fields. Change Owners should have the same permissions here as the ITIL users. The Change Manager Role and anyone in the CAB assignment unit should be able to edit all fields (excluding system generated ones like Change number or Timestamp fields like Date Opened).

2012/08/07 - 1

Requirement 546 - Change: change manager needs the ability to roll changes back

2012/08/06 - 2

Requirement 376 - Change: When submitting the risk calculation clicking on the 'submit' button should calculate (and also re-calcualte when redoing the risk calculation) the risk assessment. Should not have to click on the 'execute risk calculation' to recalculate. Marked as a higher priority requirement by Change Process team.

2012/08/03 - 1

Requirement 376 - FRU0012199 - Change: BR Fix

CSI0014

CSIaaS: Explicitly list all fields required on each record within the "csi export" views.

2012/08/03 - 3

Requirement 518 - 'Create Standard Change'

  • deactivate the 'Standard Change Template' in order to remove it from context menu (it should still be usable via the left nav module)
  • hide the template field in all cases to make things consistent w/ other applications/forms
  • delete the UI policy re: template field, since it's no longer present anyway

2012/08/03 - 2

Requirement 575 - Change: make actual start/end dates mandatory prior to change closure.

  • also include Implementation code field as mandatory at this phase

2012/08/02 - 7

Requirement 518 - FRU0012193 - 'Create Standard Change'

  • change the standard change module to use the template
  • use the reference qual for u_template to hide 'Standard Change Template' from the available template list
  • hide the template field altogether for changes where u_template == 'Standard Change Template'

2012/08/02 - 6

Requirement 562 - Change: planning information should be required in the CAB approval phase

  • change the UI policies
  • change the UI action script in the risk assessment which checks for required fields

2012/08/02 - 5

Requirement 575 - Change: make actual start/end dates mandatory prior to change closure.

  • add additional business rule in change_task to ensure fields aren't empty

06/25/2012 - 1

,Requirement RfR - FRU0011980 - Request: 'Request for Request'

2012/08/02 - 4

Requirement 423 - FRU0012195 - Change: prevent changes to fields after change is in implementation phase

  • re-enabled relevant client script

2012/08/02 - 3

Requirement 423 - FRU0012195 - Change: prevent changes to fields after change has been approved (and moved to implmentation stage)

  • except for work notes, comments, and attachments (allow for itil)

2012/08/02 - 1

Requirement 377 - Change: replace CI on Change Task screen w/ Affected Component

  • replace Configuration Item with Affected Component on Change Task form (add an insert rule for tasks created from workflow)

2012/08/01 - 1

Requirement 377 - Change: replace CI on Change Task screen w/ Affected Component

  • replace Configuration Item with Affected Component on Change Task form (on display for new records only)
  • default value of Affected Component should be that of parent change

2012/07/09 - 1

Requirement 376 - FRU0012199 - Change: Force the Risk Assessment calculation

2012/07/31 - 4

CSIaaS: role and ACLs for csi API access

2012/07/31 - 3

CSIaaS: role and ACLs for csi API access

  • repair broken perms from previous update set

CSI0013

CSIaaS: role and ACLs for csi API access

2012/07/25 - 2

Requirement 574 - FRU0012197 - Change: Reset workflow when assignment_group changed.

2012/07/26 - 1

Requirement 561 - FRU0012201 - Change: Risk Assessment should warn earlier about required fie

2012/07/26 - 3

Requirement 563 - FRU0012202 - Change: modify approval requirements

2012/07/10 - 4

Requirement 518 - FRU0012193 - 'Create Standard Change'

2012/07/25 - 1

Requirement 541 - FRU0012194 - Change:BP Workflow CAB/Unit Manager by change type post implementation task

2012/07/10 - 5

Requirement 423 - FRU0012195 - Change: prevent changes to fields after change has been approved (and moved to implmentation stage)

2012/07/09 - 2

Requirement 553 - Change, Reports: CAB Calendar View - add a highlight by change type

2012/07/08 - 2

Requirement 434 - Change: display the approval type in the related list of approvals in change_request

  • add a read-only shadow field to sys_approver called "u_approval_type"
  • add a business rule 'Set Approval Type for Change Approvals' which copies wf_activity.name to the u_approval_type field upon insert
  • add this field to the form layout in the related list in the change request form

2012/07/08 - 4

Requirement 575 - Change: make actual start/end dates mandatory prior to change closure.

  • add business rule to make these fields mandatory in the implementation phase

2012/07/08 - 3

Requirement 573 - Change: add "Application Change for Release" functionality

  • add boolean "Application Change for Release" field to change_request form
  • if enabled & prior to CAB approval, make parent change a required field (per new UI Policy)

2012/07/07 - 5

Requirement 377 - Change: replace CI on Change Task screen w/ Affected Component

  • replace Configuration Item with Affected Component on Change Task form
  • default value of Affected Component should be that of parent change

2012/07/07 - 2

Requirement 565 - Change: remove Assessment Conditions Code drop-down

  • remove assessment code field from the change form
  • comment out code in business rules which references the removed field
  • disable UI policy that references the removed field

2012/07/08 - 1

Requirement 536 - Change: add new Change Task type of "Review"

  • this requirement as originally stated was looking for ad hoc approvals, which might have caused problems for Configuration/Change process in the future. Now people will be able to create/assign change tasks to have people review changes, but approval ultimately resides with the CI owner.

2012/07/07 - 4

Requirement 564 - Change: add a 'CAB Approval Required' boolean field

  • add u_cab_approval_required (not sure if this is redundant w/ u_advisory)
  • add u_cab_approval to Change form as 'CAB Approval Required'
  • add a Data Policy 'CAB Approval Required' which sets that field to read-only if type is significant or major
  • add a Client Script 'Update CAB Approval Required' to recalculate that field if the type field changes

2012/07/07 - 1

Requirement 556 - Change: schedule end dates must be after start dates

  • add business rule 'Validate Schedule Dates' to change_request table
  • fires before insert/update
Manual Updates
  • Requirement 377 - because you can't insert js into UI policies, you have to hand-select the template in "Hide Application Change for Release for Standard Changes" (may not have to, but should check in case standard change template sys_id has changed)
  • Requirement 642 - create group in AD for CHAT_MGR; manually add chat_admin role in each instance
  • Requirement 423 - change field accessibility redux; manually add change_advisory role to CAB
  • Requirement RfR - manually add ITSM section & request to Service Catalog in each instance