--
ScottMaxson - 2013-02-12
JnJ CDX Phase2 Features (Jan/Feb 2013)
See the PM Web for specifications and the dot-project tasks and files
here
Significant development changes for this phase:
- Generate a pdf on demand from the participant's "development path" 180 asessment results screen
- Year-over-year reports for a manager's direct reports, and a global-admin year-over-year report. Export this to Excel as a formatted html table.
- Allow participants to set, edit, and remove development opportunities (as well as their manager)
- Unlock Report control moved off the development-path page an onto the manager's direct report dashboard page
- Several new email campaigns: participant without self-assessment, managers without assessments on direct-reports, etc
- Admin tool to migrate user to a new manager and optionally remove old mgr assessments as well
Deployment Notes
Setting up for deployment based on the previous "phase 1" release involves a few database changes, some setup of the assessment for the new year, enrolling all registered users (and their managers).
- The current CDX survey (ID=1) is the only active survey in the jnjcdx 360 schema. This survey needs to be cloned in order to enroll users for the new year's assessment. Cloning the survey with the survey-admin tool available to "super-admin" users should work just fine. Then put last year's survey into PO phase, and adjust the survey phase dates for the newly cloned survey. There is logic in a few places for this customer which assumes that there is only one actively enrolling survey (in either "OS" or "OE" phase) at a time, so if you leave last year's survey open for enrolling it will likely cause errors during some operations. Some of the reports, like the new year-over-year, figure the "year" of the survey by the "OS" phase date.
- Create a new "Survey Run" (an entry in SurveyGroup table) for the new survey. Participant and Respondent deadlines will appear in emails sent out, so set these to actual deadline dates.There is a stubbed-in INSERT statement in the sql-update script mentioned below, but this can be done easily through command-post as well.
- Run the statements in the DSUG/config/database/schema360_update20130129.sql script on the 360 database for jnjcdx. The important statements here are the ones that insert new types for participant email logging, which are used by the system to mark the survey-results page "unlocked" by the particiant's manager, and for the new email campaigns for CDX. There are no database schema changes to make on the 360 schema.
- Run the statements in DSUG/config/database/schema_update20130131.sql on the dsugall schema. Make sure CustomerGroup ID's are correct - the goal of the first statements are to add a column to ManagerTargetProficiency for SurveyID and set all existing records to last year's survey. This is the only schema change necessary for the new CDX features (last year when there was only one survey we didn't need to track how Dev-Opportunities mapped to surveys; this year we do!). There is an insert statement to create another new email type reminding users to refresh their dev plans (dev-plan type email campaigns are logged in the dsugall schema rather than the 360 schema). There is also an insert here to create a new registration group, so that newly registering users will get auto-enrolled into this year's survey. You may or may not want to create a distinct PIN for these new users - or just use the same PIN as the old RegistrationGroup. This PIN is hard-coded into the reigstration jsp's right now (see jnjcdx/JnJUserConfirmName.jsp).If you don't want to create a new RegistrationGroup then alter the old records in RegistrationSurvey for the existing RegistrationGroup so that users are set to be enrolled into the current survey when they self-register with that PIN.
- Enroll all registered JnJ users and their current managers into the new survey. See the attached ReEnrollUsers.ods open-office spreadsheet for a way to do this by putting registered emails and manager emails into the first 2 columns and pulling generated SQL out of the right 2 columns of the sheet. If there are incomplete manager or self assessments, or not-started assessments, from last year's survey it will be necessary to delete those from the ParticipantList table as well.
- Users who self-enroll beyond this point will be put into the new survey provided that the PIN of the RegistrationGroup is correct in step 4 above.
- Additionally, there are PreferenceOption table changes for this year's group of users. The new entries have been put into an edited version of last year's script DSUG/config/database/misc/JnJCDX_JobPreferenceOption.sql, see the notes starting on line 27 of this file. Since we have existing users whose WebUserPreference entries reference the existing Team options, this will need to be a multi-stage process of (1) marking the existing PreferenceOption "Team" entries for CDX to delete (say, by setting GNAME to 'delete'); (2) then inserting the new TEAM settings with the statements in this script; (3) then mapping all existing CDX users to the new TEAM setting. Finally, (4) the old PreferenceOption entries can be removed.
- There are several new settings required for CDX in this phase. See the attached sample file, and check the settings file that's currently used on my orion "dev" server named "scott-devapp-niobe.xml"
Implementation Notes
Many of the custom pages created for this client had some 'zero day' assumptions: when we launched in early 2012 there was only one survey available, with only one "Survey Run", so the custom pages for manager dashboard, survey results, etc just pulled up that single survey. Some of the initial work for this phase was around removing that assumption and figuring out which of the (now more than one) assessments is the 'current' one. Generally the code looks for a survey that is open for enrollment (that is, it's in a data-collection phase like "OS" or "OE" and NOT in a closed-phase "PO") and that has some participants enrolled. As noted above in the Deployment section, this client's 360 surveys should be configured so that only one survey at a time is active in "OS" or "OE" survey phase.
Related to this, there is also an email campaign and some manager dashboard logic that tries to determine whether each participant's development plan has been refreshed. The specific logic implemented here is to find the current survey, and then check the date of the 'OS' phase. Then the participant's dev plan is checked for plan items created after that date. If there are plan items (as determined by the LogCreationDate in the database table DevPlanItem) created since then, the development plan is considered up-to-date. There is some fall-back logic here that comes into play if the current survey doesn't have an 'OS' phase - in this case it just defaults to the first day of the current calendar year. However, during regular production support this shouldn't be needed - it's just there to try and make the logic more robust.
Some of the reports, like the year-over-year report, also differentiate surveys based on start-date of the "OS" open-enrollment phase. For this report to work as intended there should be only one survey with a "OS" phase per calendar year. Year-over-year report generation may take a few seconds to a minute or more depending on the manager's list of direct reports, so there is a 'please wait' style page put in to keep users informed of what's going on. This may not turn out to be absolutely necessary, but it's a safe and easy way to keep users from clicking the link multiple times. See the class
ReportByParticipant180History for the current implementation of the year-over-year reporting.
The on-demand PDF version of the developmental path borrows several classes/methods used in 360 pdf generation. These have been re-factored into the base class
PdfBaseReportRunner. Building a report using server code which is run in the main thread, rather than as a background thread or process, is something new -- we'll have to keep an eye on this and make sure that there are no memory issues (leaks) or other system resource problems introduced by this feature (
NB: highlight this for pre-release testing).