2013-04-12 Release

Summary

primarily indcident, request defect fixes for level setting of test cases
latent tweaks to unpublished catalog items in development
latent START replacement foundational work

Current Status Board

(if you can see this message, your browser probably sucks)

Progression

Status	Activity	Description	Duration
	Submit change request	Open a build/test change request in https://yale.service-now.com/, assign to `INF SN App Support`	minutes
	Schedule code review (Mon 1pm)	this should happen after initial handover and before release	minutes
	Build phase work	Begin work in dev	days
	Unit tests	Ensure all pushed to tst & unit tested	hours
	Initial code freeze	Hand over initial requirements list for functional & QA validation in tst	minutes
	Conduct code review	Shouldn't take long, just basic validation of approach and docs	hours
	Defect fixes	Iterative follow-up work in dev, test for defect resolution	days
	Finalize release	Identify changes & updates that are going/not going. Push to (tst).	hours
	Final code freeze	Hand over final requirements list for functional & QA validation, w/ regression, in (tst)	minutes
	Go/no-go	Decide to push to production.	minutes
	Production deployment	Push to prd.	hours
(n/a)	Production rollback	If applicable; follow ServiceNow Rollback Procedure.	hours
	Clone	clone from prd to: pre, trn, and tst for after release	hours
	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

CHG0006132

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.

Approved Updates

Update_Set_Name	Description
2013/04/10 - 3	START DEFECT 3: Pager add new, use case for group pager. The quantity feature should only accept positive integers. This was not explicit in the requirements, but we should intuitively know this. The form does not accept letters. But it previously accepted negative numbers, as well as floating point numbers. Fixing this.
2013/04/10 - 2	START DEFECT 2: Catalog items for pager should not have quantity as part of the submit / cart widget. This was in the requirements, and left out. Fixing.
2013/04/10 - 1	START DEFECT 1: Catalog items for pager should have shopping cart. This was in the requirements, and left out. Fixing.
2013/04/09 - 2	Defect 453: Closed Incidents showing up in the Incidents -> Open query in the Incident module in the left hand menu. This query should not show Closed or Resolved Incidents.
2013/04/08 - 1	CMDB: provide a data source, import, transform and schedule for the business service and provider service data. See http://isa.its.yale.edu/confluence/display/SN/CMDB+Services+Data+Contract
2013/04/09 - 1	START requirement 69: Enhancement Description: PTAEO prevent submission if invalid This is just a quick fix to an out-of-order deployment situation. Making a fix to one script which was breaking PTAEO submission. This affects three variable sets: PTAEO initial, PTAEO recurring, PTAEO initial and recurring
2013/04/05 - 2	FRU0013928 - START Requirement 67: New catalog item Pager: Change existing Create a new Service Catalog Item per the following parameters: Title: Pager: Change existing Visible to: anyone Description: This service request allows you to change properties on an existing pager
2013/03/20 - 2	FRU0013927 - START Requirement 66: New catalog item Pager: Add New Create a new Service Catalog Item per the following parameters: Title: Pager: Add New Visible to: anyone Description: This service request allows you to request a pager on behalf of yourself or others
2013/04/05 - 1	FRU0014122 - START Requirement 74: Modify PTAEO backend for sending SYSDATE to SOAP service Enhancement Description: Modify PTAEO backend for sending SYSDATE to SOAP service When I initially coded the backend connection to SOAP service, I hardcoded a date in the proper format. That was good enough for a proof of concept, but we need to make this be a real date, set to current date, formatted in the proper format as accepted by the SOAP service.
2013/04/03 - 1	FRU0013930 - START requirement 69: Enhancement Description: PTAEO prevent submission if inval Enhancement Description: PTAEO prevent submission if invalid Right now the only protection preventing submission on bad PTAEOs is if they were never entered at all. We need a shadow variable and an onSubmit script or some combination of technology which detects whether the PTAEO is valid or invalid during the submit. If invalid, it should prevent the submit and force the user to correct the bad PTAEO before the submit can succeed. This affects three variable sets: PTAEO initial, PTAEO recurring, PTAEO initial and recurring