Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 133 Current »

Summary

This release primarily involves:

  • Knowledge Base: various modifications to permissions, form, behavior (2)
  • Request: new entries in Service Catalog: (5)
    • Infrastructure: new virtual machine (Requirement 656)
    • ServiceNow: Assignment Group update (Requirement 657)
    • ServiceNow: template/report publishing (Requirement 664)
  • Filters: DSP Queries (4)
  • Incident: Bomgar Integration (3)
  • Email Notifications: format, content, conditions (1)
  • A small number of defect fixes

Progression

Time until release:

Unknown macro: {html}

<script language="JavaScript">
TargetDate = "10/11/2012 9:00 PM";
BackColor = "white";
ForeColor = "navy";
CountActive = true;
CountStepper = -1;
LeadingZero = true;
DisplayFormat = "%%D%% Days, %%H%% Hours, %%M%% Minutes, %%S%% Seconds.";
FinishMessage = "It is finally here!";
</script>
<script language="JavaScript" src="http://scripts.hashemian.com/js/countdown.js"></script>

Status

Activity

Description

Duration

(tick)

Identify release date 9/27 (pushed to 10/11)

see Release Calendar

minutes

(tick)

Schedule cloning

clone from prd to: pre, trn, and tst for after release; https://hi.service-now.com/

minutes

(warning)

Schedule code review

this should happen after initial handover and before release

minutes

(tick)

Submit change request CHG0003347

Open a build/test change request in https://yale.service-now.com/, assign to INF SN App Support

minutes

(tick)

Start release document

Copy from template ServiceNow Release YYYY-MM-DD

minutes

(tick)

Requirements freeze

Curate, then freeze requirements, providing estimates for each using estimator spreadsheet or equivalent

hours

(tick)

Build phase work

Begin work in dev

days

(tick)

Unit tests

Ensure all pushed to tst & unit tested

hours

(tick)

Initial code freeze

Hand over initial requirements list for functional & QA validation in tst

minutes

(tick)

Conduct code review

Shouldn't take long, just basic validation of approach and docs

hours

(tick)

Defect fixes

Iterative follow-up work in dev, test for defect resolution

days

(tick)

Finalize release

Identify changes & updates that are going/not going. Push to pre.

hours

(tick)

Final code freeze

Hand over final requirements list for functional & QA validation, w/ regression, in pre

minutes

(tick)

Go/no-go

Decide to push to production.

minutes

(tick)

Production deployment

Push to prd.

hours

(n/a)

Production rollback

If applicable; follow ServiceNow Rollback Procedure.

hours

(tick)

Notify stakeholders

send out email w/ summary status & link to release documentation, close out RFC and cancel clone requests, if rollback or no-go.

minutes

 

Target/Actuals

Deliver target/actuals using estimator spreadsheet or equivalent

hours

Change Control

CHG0003347
CHG0003902 (emergency change to fix SAML regression)

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

Requirement (Original Names)

Functional Tested?

QA Tested?

Dev Status Notes

Description

584

(tick)

(tick)

(tick)

Knowledge: Allow all ITIL users the ability to create a new KB Submission. They should see the 'Submissions' section and nothing else under this menu. There should be an item added to the Submissions section that says 'Create New Submission'. Clicking on this would create a new SUB ticket, not a KB ticket. See attachment for screen shot.

588

(tick)

(tick)

(tick)

When a KB article is created fill the 'role' field by default with the 'itil' role.

533

(tick)

(tick)

(tick)

Currently the published date is prepopulated with today, even though the submission is in draft state. That field should be blank, non-required, until the article is published. Once the article is put into published status and saved, the published date field should be mandatory and auto-filled with the date the article is put into published status. Lori would prefer that the published date be a non-editable field, it should just be set when the workflow requires it.
(The other reason that the published date being mandatory and a date after today being annoying is that anytime I want to save a draft I have to update the date to today or a future date. This seems counterintuitive.)
Move the published date field down towards the bottom of the screen in the 'Activity' section with the author, created, updated by and updated fields.

585

(tick)

(tick)

(tick)

Knowledge: When KB Submissions are created they should automatically be assigned to MGT Knowledge Management queue. They are currently not assigned to any unit and Lori must go in and manually assign them to her assignment unit.

387

(tick)

(tick)

(tick)

User comments should not be shown on the published Knowledge record. Only folks with the knowledge manager role should be able to see feedback left on the KB article. Note that if the ability to view the user comments cannot be restricted to just the folks with the Knowledge Manager role just remove the ability to submit feedback comments.

660

(tick)

(tick)

(tick)

Knowledge: Information from the Incident (Text, Submitted By) should be pulled into the KB Submission when it's created from an Incident.

661

(tick)

(tick)

(tick)

Knowledge: All the 'Save and Exit' button to the Create Article knowledge screen.

516

(tick)

(tick)

(tick)

This is an example of an email to a Client from the Service Now system. Can the wording be changed when a work order is put on "Hold" where it says that "Your ticket has been placed on hold because we require additional information from you" My Client's understand why the work order has been placed on Hold but are getting confused because it says that "we require additional information from you".
How about something like this, "Your ticket has been placed on Hold. You can click on the following link to check the status of your ticket."
submitted by Marty Wallace/John Martino
Please note these are covered in the attachment for Requirement #659.

364

(tick)

(tick)

(tick)

When an Incident is put on hold the 'additional comments' field is required to let the customer know why their Incident was put on hold. This is OK. However when the ticket is updated with ANY update when the Incident is on hold the additional comments field is required and when this field is updated it sends a notification to the client/contact. Sometimes the tech or someone else needs to update the work notes or change a categorization or assignee and the client should not receive an update. This 'additional comments' field needs to be required ONLY when the ticket is placed on hold and not for subsequent updates afterwards.

481

(tick)

(tick)

(tick)

Email Notification: List the resolution in the ticket in closure email notification so folks know how the issue was resolved. Please note these are covered in the attachment for Requirement #659.

432

(tick)

(tick)

(tick)

Incident Email Notification Modifications per Dawn Colonese. Please note these are covered in the attachment for Requirement #659.
1) On all email notifications add a link to the ticket referenced in the notification.
2) On email notifications to the client that let them know the ticket has been opened include the name of the person who opened the ticket. If no person opened ticket (e.g. via email intake) no name added, just include the service desk contact information.
3) On any follow up email notification to the client include the Incident assignee's name in the signature. If there is no assignee then it's the person who started the ticket.

659

(tick)

(tick)

(tick) - iterate on defect fixes

Make Changes to Customer Facing Incident Email Notifications. See attachment for text.

662

(tick)

(tick)

(tick)

Queries: Create a special query for the DSPs so they may view and sort their work by DSP contract.

664

(tick)

(tick)

(tick)

Request for New Request Type: RITM0017469. This request will allow you to publish or share a template or a report with another assignment group. Requested by/for the ITSM team.

657

(tick)

(tick)

(tick)

This service request allows you to request adding or removing staff from ServiceNow assignment groups. Requested by Adriene Radcliffe.

656

(tick)

(tick)

(tick)

This will request a virtual machine in the Enterprise VMware infrastructure. Requested by Mike Caplin on behalf of John Coleman.

663

(tick)

(tick)

(tick)

General System: Integrate ServiceNow with Bomgar

Defects

Defect

Verified?

Dev Fixed?

Verified?

Description

375

(error)

(n/a) emails were sent & received for both incidents

(tick)

Sept 27 Release Testing: Client facing emails not being sent from TEST system. Creating a new ticket, updating the ticket and resolving the ticket are not sending emails from the system to the customer. The ticket is being updated with the updates however no email is being sent. See INC0053338 or INC0053340 for an example.

376

(tick)

(tick) added a column for SCTASK dotwalk

(tick)

Sept 27 Release Testing: The DSP Query is not showing the CONTRACT, the field in the query output is blank. We need to see the short description in the SERVICE CONTRACT in this spot.

377

(tick)

(tick) this didn't carry over in update set, made a note for manual change during deployment

(tick)

Sept 27 Release Testing: Assignment Group not set to INF SN App Support for SC Tasks for request for SN Assignment Group changes. Request creates RITM correctly and creates SC Tasks correctly however they are not assigned to SN INF App Suppoprt assignment group.

378

(tick)

(tick) with caveats, see description

(tick)

Multiple defects in the Add/Remove SN Assignment Group Membership:
(error) 1. Form behavior - In a case where a user is request more than one change - after clicking the "Add to Cart" button, the "Select Staff Member" field should be reset so there is no entry. as-is it's a more efficient design... either group or user may stay the same for next entry.
(tick) 2. RITM - The Client and Contact fields display but without the field names listed
(error) 3. RITM - on the Remove items, the Queue Manager is extraneous. This does not effect the operation, it may just appear confusing to someone looking at the resulting RITM (not a show stopper) this is the way it works for all requests... unless we open a separate defect for it, it doesn't make sense to address it at this early stage
(error) 4. RITM - Estimated Delivery should be set to 2 days in all cases was it in the release requirements to start using this field?
(error) 5a. Resulting SCTASK - has "Requested for" which should be Client, was this in the release requirements to change the sctask form?
(tick) 5b. [Resulting SCTASK] does not show Contact, does not show the variables for staff member being added/removed, or queue manager value
(question) 6. Notifications should be sent to CONTACT on completion, but I could not test that not clear what this means, because there is an existing notification for the parent request that goes to requested_for, and then there are fulfillment notifications for each request item; these go to the contact. I've changed the request notification to opened_by.

379

(tick)

(tick)

(tick)

Defect/enhancement reported from Mike Caplin:
1. "Template to be deployed" variable does not prop over to related SCTASK
2. Enhancement - Can TEXT field at the bottom for form titled "Additional Information". Prop that to both the RITM and SCTASK

380

(tick)

(tick)

(tick)

Email notification 1B (Incident created via self-service portal or email) is missing a word in the subject line. Please add the word 'Received' to the subject. It should read "Request for ITS Support Received - Ticket Number: XXXXX"

381

(tick)

(tick) yes, this is a non-issue, the URL is parametrized

(tick)

This may be a non-issue and the link may be updated when the email notifications are moved to Prod but once moved to Prod the links to tickets in the email notifications should point to PROD and not TEST.

382

(tick)

(tick) OK

(tick)

Sept 27 Release Testing: Email notifications should point customers to the new ITS web site instead of the old web site. Need to see when the ITS web site is going live and if it is going live before we release we should update the links in our email notifications to point to the new web site. Assigning to Chloe to research the website go live date and the links.

383

(tick)

(tick)

(tick)

September 27 Release Testing: Email Notification 4 (Incident Resolved) needs one word updated in the body. Where it says "Click here to go your ticket" it should read "Click here to review your ticket". Just change "go" to "review".

384

(tick)

(tick)

(tick)

Sept 27 Release Testing: When an Incident is put on hold the customer is getting BOTH email #2 (Incident on hold) and email #3 (Incident Updated). When an Incident is put on hold the customer should receive ONE email "Incident has been put on hold". They should not receive the Incident Updated (#3) email as well.

385

(tick)

(tick) fixed to show only latest comment, w/o metadata or styling

(tick)

Sept 27 Release Testing: Email Notification #2 and #3 should not have lines and date/time/updatedby stamp and should only contain the most recent comment update.

386

(tick)

(tick)

(tick)

When creating a Request to share a new Template, the RITM screen requires that a Report be selected, in additon to the Template that has been selected. See RITM0017351, e.g.

387

(tick)

(tick) blank assignment unit was present, so it was saving something; the correct groups don't carry over properly in update sets; this will be handled manually during deployment.

(tick)

When creating a Request to share a Report, the Task was closed without filling out the required field for Assignment Group. See, e.g., SCTASK0017307 and 17308.

388

(tick)

(tick) commented out apparently superfluous sc_req_item events that had been added by Fruition

(tick)

When creating a Request to share a Report, I rejected the Request and received both the Rejected and Approved notifications. See RITM0017353 and attached screenshot.

390

(tick)

(tick) fixed all matching notifications

(tick)

In the email notification footers of new Incident notifications please change links from/to the following:
Change www.yale.edu/its to

http://its.yale.edu/

Change www.yale.edu/its/servicenow to

http://its.yale.edu/its-technology-ticketing-system-service

391

(error)

(n/a) couldn't replicate, confirmed non-bug w/ Dorothy

(tick)

Requirement is that only those with the Knowledge Manager role can see the user comments. Currently not even the Knowledge Manager can see the user comments, they are blocked from everyone. Submitted by Dorothy Ortale.

392

(error)

(n/a) this appears to be a problem w/ mailman, not SN

(tick)

In email notification 1B the subject has too many spaces between 'Ticket Number:' and the Incident number. It looks like it's a tab and not a couple of spaces.

393

(tick)

(tick)

(tick)

Request to ADD/Remove staff from SN Assignment Group the staff member variable being added or removed does not come over to the SCTASK

395

(tick)

(tick)

(tick)

Request for ITS Support Resolved notification link, guidance incorrect

Approved Updates

Update Set ____________________

Description

2012/09/23 - 1

Requirement 584 - Knowledge: Allow all ITIL users the ability to create a new KB Submission.

  • They should see the 'Submissions' section and nothing else under this menu (bw - assuming OOB link to r/o KB view is acceptable).
  • There should be an item added to the Submissions section that says 'Create New Submission'. Clicking on this would create a new SUB ticket, not a KB ticket.
  • There are manual steps that go with this (ensure knowledge role is not granted to SERVICE_Desk_Queue_MGR group)

2012/09/23 - 2

Requirement 588 - When a KB article is created fill the 'role' field by default with the 'itil' role.

  • change default value in dictionary of kb_knowledge.roles

2012/09/23 - 3

Requirement 533 - Knowledge: Increase automation of published date field

  • published date should be blank, non-required, until the article is published.
  • as an the article is put into published status, the published date field should be auto-filled with the date the article is put into published status.
  • the published date should be a non-editable field; it should just be set when the workflow requires it.
  • move the published date field down towards the bottom of the screen

2012/09/24 - 1

Requirement 585 - Knowledge: When KB Submissions are created they should automatically be assigned to MGT Knowledge Management queue.

  • not sure what I was smoking when I did this, because it's very wrong.

2012/09/24 - 2

Requirement 387 - Knowledge: User comments should not be shown on the published Knowledge record.

  • Only folks with the knowledge manager role should be able to see feedback left on the KB article.

2012/09/24 - 3

Requirement 660 - Knowledge: Information from the Incident (Text, Submitted By) should be pulled into the KB Submission when it's created from an Incident.

2012/09/24 - 4

Requirement 661 - Knowledge: All the 'Save and Exit' button to the Create Article knowledge screen.

2012/09/24 - 5

Requirement 364 - Incident: Comments should only be required if state is changing to On Hold
When an Incident is put on hold the 'additional comments' field is required to let the customer know why their Incident was put on hold. This is OK. However when the ticket is updated with ANY update when the Incident is on hold the additional comments field is required and when this field is updated it sends a notification to the client/contact. Sometimes the tech or someone else needs to update the work notes or change a categorization or assignee and the client should not receive an update. This 'additional comments' field needs to be required ONLY when the ticket is placed on hold and not for subsequent updates afterwards.

  • add a client script that only sets the field as mandatory when the incident state is changed
  • deactivate the less flexible UI policy that previously made this field mandatory

2012/09/24 - 6

Requirement 516 - Email Notifications: remove mention of 'additional information' from incident on-hold email notification.

  • replace w/ 'Your ticket has been placed on Hold. You can click on the following link to check the status of your ticket.'
  • approved copy can be found in the QC requirements

2012/09/25 - 1

Requirement 481 - Email Notifications: List the resolution in the ticket in closure email notification so folks know how the issue was resolved.

  • includes significant changes to text; approved copy found in QC requirements, used w/ slight modifications to clarify instructions for end user.
  • enable the Reopen Incident button, as implied by the supplied message

2012/09/25 - 2

Requirement 432 - Email Notifications: Standardize copy & fields
1) On all email notifications add a link to the ticket referenced in the notification.
2) On email notifications to the client that let them know the ticket has been opened include the name of the person who opened the ticket. If no person opened ticket (e.g. via email intake) no name added, just include the service desk contact information.
3) On any follow up email notification to the client include the Incident assignee's name in the signature. If there is no assignee then it's the person who started the ticket.

  • created new, separate notification for ESS/Email incident intake. As before, this does not work w/ Guest, since reply address for Guest is not stored by inbound email action.
  • deviation from req: ESS/Email notification is addressed to opened_by instead of contact, since in the ESS case there is no contact per current behavior
  • deviation from req: supression of create notification is conditional on Incident State, rather than FPOC, since FPOC does not behave as described in the req

2012/09/25 - 3

Requirement 659 - Email Notifications: Make Changes to Customer Facing Incident Email Notifications. See attachment for text.

  • these are all dealt w/ in previous sets, so nothing much here
  • implied fix - correct the outgoing email display name (was ITS Help Desk)

2012/09/25 - 4

Requirement 662 - Queries: Create a special query for the DSPs so they may view and sort their work by DSP contract.

  • this will be done with filters and views
  • Filter: DSP Manager Groups' Work
  • Filter: DSP Groups' Work
  • Filter: DSP My Work
  • View: will attempt to show tasks with these columns
    • number
    • opened_at
    • priority
    • status
    • short description
    • client name
    • DSP contract name
    • assigned to
    • assignment group
    • incident location
    • SLA
    • SLA time left

2012/09/25 - 5

Requirement 664 - Request: Request for New Request Type: RITM0017469. This request will allow you to publish or share a template or a report with another assignment group. Requested by/for the ITSM team.

2012/09/25 - 6

Requirement 657 - Request: This service request allows you to request adding or removing staff from ServiceNow assignment groups. Requested by Adriene Radcliffe.

2012/09/26 - 1

Requirement 657 - Request: This service request allows you to request adding or removing staff from ServiceNow assignment groups. Requested by Adriene Radcliffe.

  • includes global business rule filterUserByGroup() for reference qualifier in user field

2012/09/26 - 2

Defect 374, Requirement 585 - Knowledge: When KB Submissions are created they should automatically be assigned to MGT Knowledge Management queue.

  • correcting earlier mistake made when trying to implement req 585.

2012/09/26 - 3

Defect 376 - DSP Query not showing contracts for requests. Need to dot-walk a different column to get this info for requests.

2012/09/26 - 4

Defect 377 - Assignment group not properly set in task generated by new service management request; try to recapture this.

2012/09/26 - 5

Requirement 656 - Update "Service Category" table in ServiceNow
How Can We Help You? - keep this existing category
Service Management - keep this existing category
Remove
Personal Productivity Support
Security
Telecom
Service Management
Application Management
Access
Infrastructure Management
Add:
Accounts and Access
Backing Up, Storage and Servers
Client Teams and Business Systems
Collaboration and File Sharing
Computer and Device Support
Computer Labs and Printing
Email and Calendars
Phones and Cable TV
Teaching and Learning
Research Technologies
Web and Application Services
Wifi and Networks

2012/09/27 - 1

Defect 378 - defects in SN group modification catalog item

  • The Client and Contact fields display but without the field names listed
  • Resulting SCTASK does not show Contact, does not show the variables for staff member being added/removed, or queue manager value

2012/09/27 - 2

Defect 378 - defects in SN group modification catalog item; Notifications should be sent to CONTACT on completion

  • modified the task-specific notification in the workflow to go to current.variables.contact

2012/09/28 - 1

Defect 378 - defects in SN group modification catalog item; Notifications should be sent to CONTACT on completion

  • modified the pre-existing sc_request.inserted notification in the workflow to go to opened_by (since contact is item-specific)

2012/09/28 - 2

Defect 379 - Defect/enhancement reported from Mike Caplin:

  • Add a TEXT field at the bottom for form titled "Additional Information". Prop that to both the RITM and SCTASK

2012/09/28 - 3

Defect 379 - Defect/enhancement reported from Mike Caplin:

  • "Template to be deployed" variable should propagate to related SCTASK

2012/09/28 - 4

Defect 380 - Email notifications:

  • notification 1B (Incident created via self-service portal or email) is missing a word in the subject line. Please add the word 'Received' to the subject. It should read "Request for ITS Support Received - Ticket Number: XXXXX"

2012/09/28 - 5

Defect 383 - September 27 Release Testing: Email Notification 4 (Incident Resolved) needs one word updated in the body. Where it says "Click here to go your ticket" it should read "Click here to review your ticket". Just change "go" to "review".

2012/09/28 - 6

Defect 384 - Sept 27 Release Testing: When an Incident is put on hold the customer is getting BOTH email #2 (Incident on hold) and email #3 (Incident Updated). When an Incident is put on hold the customer should receive ONE email "Incident has been put on hold". They should not receive the Incident Updated (#3) email as well.

2012/09/28 - 7

Defect 385 - Sept 27 Release Testing: Email Notification #2 and #3 should not have lines and date/time/updatedby stamp and should only contain the most recent comment update.

2012/09/28 - 8

Defect 386 - When creating a Request to share a new Template, the RITM screen requires that a Report be selected, in additon to the Template that has been selected. See RITM0017351, e.g.

2012/09/28 - 9

Defect 388 - When creating a Request to share a Report, I rejected the Request and received both the Rejected and Approved notifications. See RITM0017353 and attached screenshot.

2012/10/01 - 1

Defect 390 - In the email notification footers of new Incident notifications please change links from/to the following:
Change www.yale.edu/its to

http://its.yale.edu/

Change www.yale.edu/its/servicenow to

http://its.yale.edu/its-technology-ticketing-system-service

2012/10/02 - 1

Defect 393 - Request to ADD/Remove staff from SN Assignment Group the staff member variable being added or removed does not come over to the SCTASK

2012/10/02 - 2

Defect 378 - Multiple defects in the Add/Remove SN Assignment Group Membership:

  • reversing a change to this workflow; it doesn't make sense for a RITM to munge a field in the parent request if there can be multiple RITMs.

2012/09/21 - 1

Requirement 663 - Fruition Bomgar Standard Integration (Baseline)

2012/09/21 - 2

Requirement 663 - Fruition Bomgar Standard Integration (Install)

2012/10/03 - 1

Requirement 663 - Fruition Bomgar Standard Integration (Install)

2012/10/03 - 2

Defect 385 - Sept 27 Release Testing: Email Notification #2 and #3 should not have lines and date/time/updatedby stamp and should only contain the most recent comment update.

  • The 'The Incident has been updated' needs a blank line between the short description and the 'If you wish to provide additional info..."
  • The "Incident is on hold' email is still showing the date/time/updated by stamp and is showing all comments made and not just the most recent one.

2012/10/04 - 1

Defect 385 - Sept 27 Release Testing: Email Notification #2 and #3 should not have lines and date/time/updatedby stamp and should only contain the most recent comment update.

  • 'incident updated' needs bare newline after 'Dear name'
  • 'incident on hold' has extra bare newline after comments

2012/10/09 - 6

Defect 395 - "Request for ITS Support Resolved" notification link, guidance incorrect

2012/10/12 - 1

Requirement 663 - Fruition Bomgar Standard Integration (Install)

  • adjust properties (no stub incidents, include FQDN in server name

2012/10/15 - 1

Requirement 634 - ESS: Fix for SAML to do deep linking fix for ESS

  • SAML login script comments captured, carried to prod in last release. This reverses that change.
Manual Updates
  • Req 584 - ensure 'knowledge' role not granted to SERVICE_Desk_Queue_MGR group
  • Req 656 - manually add Infrastructure category to Service Catalog
  • Requirement 659 - manually change email outgoing name to "Yale University ITS", since this didn't stick in the update set for some reason
  • Requirement 657 et al (all request workflows) - check & manually edit workflow "Item: SN Group Membership" to ensure that the fulfillment group is set correctly. This was not properly captured despite several attempts.
  • No labels