SSP-1827 Reload Template Store when showing Template chooser
SSP-1809 Continue Liquibase if uP tables not present in SSP database
SSP-1833 Copy Referral links into MyGPS-created Tasks

Also includes a Liquibase changeset for updating existing Tasks.

Conflicts:
	src/main/resources/org/jasig/ssp/database/changesets/000082.xml
	src/main/resources/org/jasig/ssp/database/masterChangeLog.xml

Conflicts:
	src/main/resources/org/jasig/ssp/database/masterChangeLog.xml
SSP-1822 Fixed template print for View All button

Conflicts:
	src/main/webapp/app/service/MapPlanService.js
NOJIRA Handle disabled isPrivate Template save checkbox
SSP-1839 server side fix for improper exposure of Plan Template create, save and delete
SSP-1839 Allow public->private template conversion without pub perm

Previously a user without MAP_PUBLIC_TEMPLATE_WRITE couldn't make any
changes to a public template. Now we'll allow such users to demote it
to private, which should be just fine, either because it's your own
template, or it was somebody else's in which case the edit creates a
copy.
SSP-1828 Default to Template objectStatus value in save dialog

In edit mode we want the "Active Template" checkbox to be checked or
not depending on current Template objectStatus. In create mode we
want the checkbox to not be checked, i.e. create an inactive Template,
e.g. to support a quasi-"draft" mode.

The create mode behavior just happened to work previously, but the edit
mode behavior did not. This was because the form was being reset
on "show", so it was mostly by accident that either case worked.

But when I moved the line that initializes the activeness checkbox
into the show event handler, I noticed that edit mode exhibited the
opposite behavior, i.e. always checked rather than always unchecked.

This was because the JSON deserialization was running against a
singleton Plan model. The latter extends from AbstractBase, and uses
populateFromGenericObject() on it to consume the JSON. Because the
target object had already been initialized once, though, the flags it
used to coordinate between 'active' and 'objectStatus' fields had
been set in such a way (statusFieldsInitialized=true) that when
'active' was then set again, and with a null or undefined value (which
will always be the case when reading an object back from the server),
it thought the change was coming from the UI, not the server, and would
overwrite the value of 'objectStaus' back to the default ('ACTIVE').
SSP-1828 Default new Plans to active

When in edit mode, the proposed active state will be the Plan's current
status. This worked in rel-2-0-patches for 2.0.1 as of
dac9036fbd2f43eb93bfb83c400db0af111a0c9d and appears to match the
current behavior in 2.1.0 at the same time.

That *new* Plans were defaulting to inactive, though, appears to
have been a regression from dac9036fbd2f43eb93bfb83c400db0af111a0c9d.
SSP-1828 Force Template to inactive in all save-as scenarios

So now the Template save dialog will propose an inactive status in
two situations where it didn't previously:

  1) Saving a copy of a previously saved, active Template, and
  2) Saving a Template-ized copy of a previously saved, active Plan
Revert "SSP-1794"

This reverts commit a95aa782a06d616711fa0230fbec49661c46451d.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
Revert "SSP-1760"

This reverts commit a2c7682415b7d587161ae8706b854454b7a4bc52.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
Revert "SSP-1760"

This reverts commit c6328eec7c219e421125ab6de847708dfe3a68dd.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
SSP-1828, SSP-1760 Restore useful line from a2c7682

I reverted a2c7682 because I felt later work on SSP-1828 resulted in
simpler changes that accomplished the same thing w/r/t synchronization
of objectStatus and active fields in the client-side model. But this
line, which makes sure the defaulting of objectStatus is reflected
in the value of the active field, was a helpful change that SSP-1828
did not address. So this commit restores it.
SSP-1828 Default several reference types to active in admin UI

Sets EnrollmentStatus, Color, and Tag records to active by default
when being created by the admin UI. Closely related to work
originally done in SSP-1794 and SSP-1760, but officially filed with
SSP-1828 because that ticket changed the approach a bit for managing
the 'active' and 'objectStatus' field synchronization, which I think
then created a regression that those other tickets had worked around.
Fix Map window scrollbar code to be active again
NOJIRA Fix spelling in move plan dialog
SSP-1848 Find conflicting person records by constraint-violated field

The race condition reported in this ticket was the standard race where
we have multiple threads trying to create a person at the same time.
Usually we address this by falling back to looking up the existing
person after one such thread beats all the others to the commit.

But this particular situation was failing to resolve itself because
the person.username uniqueness constraint was being violated, but the
subsequent lookup was by schoolId and that schoolId didn't match the
schoolId on the person record that caused the violation.

This sort of thing can happen in the real world where the portal
doesn't have access to correct schoolIds, so uses username as both
schoolId and username. So on a first name login thread 1 and thread 2
try to find a person record with username X. Neither find it, so both
try to create that user. Thread 1 does so first, which includes copying
the latest data from external_person onto it such that person.username
and person.school_id match those fields in external_person, not
necessarily whatever was provided by the portal. Then Thread 2 tries
to create another person with username X, which violates the uniqueness
constraint on that column. It would then try to look up that existing
record *by schoolId*. This would yield no results if that field no longer
matched username because it had been "corrected" by the external_person
sync. This would then invalidate the current SpringSecurity context.

The fix was to always look up the existing record using the value of
the column on which the uniqueness violation occurred.
SSP-1847 Fix transcript pop-up

This changes the transcript pop-up to be a size as a percentage of the browser window as well as adds a vertical scrollbar."

Conflicts:
	src/main/webapp/app/view/tools/map/StudentTranscriptViewer.js

Upstream changes had added a 'style' config to set the z-index. Conflict
resolution was trivial.
SSP-1846 Fix transcripted courses don't move MAP