Versions Compared

Old Version 2

changes.mady.by.user Jason Elwood

Saved on

compared with

New Version 3

changes.mady.by.user Jason Elwood

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Add the Watch Student feature
  • Add bulk actions for Caseload and Search Results (IE: email, export, change program status)
  • New Early Alert Reports
  • Significant Report fixes
  • All stability improvements and bug fixes included in the v2.5.X releases

 

Info

There are no external database schema changes in this release

...

SSP-2817 made additional changes to the SSP-Platform ant build script to try to work around continued problems with corrupt Maven dependency downloads. Deployers clean out possibly corrupt dependency downloads before updating SSP and/or Platform build to v2.6.0.  The Maven repo base is where the .M2 directory exists (IE env variable = MAVEN_HOME)

...

Info
  • Unix/Linux
    • rm -rf <repo-base>/net/sf/ehcache
rm -rf <repo-base>/org/jasig/cas/client
  • Windows
    • delete folder <repo-base>/net/sf/ehcache
    • delete folder <repo-base>/org/jasig/cas/client

...


2 - Update to java 1.7

Java 1.7 is now required and the only version of java that SSP will use.  Once the code branch has been pulled into the local repository, the Platform API must be built prior to deploying SSP Platform as shown below:

Code Block
cd <SSP-Platform source>/uportal-java-api
mvn clean install

 

3 - Adjustments to Single Sign-On (SSO) Person Lookup Filtering

  1. This upgrade step ONLY applies to implementers that source person attributes from AD/LDAP AND end users may have more than one entry among all the searchable AD/LDAP branches currently configured in SSP Platform.  There are multiple steps to properly configure the lookup filtering as described below.  

    1. <platform-src>/uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml - Each LDAP DAO requires a line similar to the following in its resultAttributeMapping map:

      Code Block
      <entry key="distinguishedName"><value>distinguishedName</value></entry>

In all cases the <value> must be 'distinguishedName'. The key might be directory-specific. E.g. in Apache DS, the correct config is:

<entry key="entryDN"><value>distinguishedName</value></entry>



    2. Make distinguishedName visible. Run this command from <platform-src> (all one line) to import the updated permissions:

      Code Block
      SSP_CONFIGDIR=/path/to/ssp/config ant -Dmaven.test.skip=true
-Dfile=uportal-war/src/main/data/ssp_entities/permission_set/Everyone__VIEW_USER_ATTRIBUTE__distinguishedName.permission-set.xml
data-import



    3. <ssp-config-dir>/ssp-platform-config.properties - Specify the filtering strategy as described by comments in <platform-src>/uportal-war/src/main/resources/properties/ssp-platform-config.default.properties.  As noted in those comments, if you choose PreferredBaseDnPersonAttributesFilter or RequiredBaseDnPersonAttributesFilterbe sure to specify the prioritized DN. E.g. for an imaginary and very simple directory.

      Code Block
      # Spring pseudo-URL pointing to a Groovy implementation of IPersonAttributesFilter
# suitable for filtering person directory lookups for end users hitting the
# portal via the /sso API. OOTB options:
#
#   classpath:org/jasig/portal/portlets/lookup/NoOpPersonAttributesFilter.groovy - Default. Does nothing.
#
#   classpath:org/jasig/portal/portlets/lookup/RequiredBaseDnPersonAttributesFilter.groovy - Limits directory search
#      results to only those persons associated with the baseDn configured by an additional property set in this
#      file. E.g. to limit SSO to users in the 'faculty' branch of an imaginary LDAP directory:
#
#        environment.build.sso.personFilteringBaseDn=ou=faculty,o=persondir
#
#      For this to work, personDirectoryContext.xml DAOs must be configured to expose a logical attribute named
#      'distinguishedName'

#   classpath:org/jasig/portal/portlets/lookup/PreferredBaseDnPersonAttributesFilter.groovy - Similar to
#      RequiredBaseDnPersonAttributesFilter but allows results not associated with
#      environment.build.sso.personFilteringBaseDn. I.e. if an end user has multiple directory entries with the same
#      environment.build.sso.personDirectoryUuidAttributeName (see below) and that attribute is being used as the
#      lookup key, choose the entry associated with environment.build.sso.personFilteringBaseDn, if any. Otherwise
#      return all results (which may result in an error downstream). Use this is you want to allow SSO for
#      users in a variety of base DNs, but need a policy for narrowing down entries for certain users.
#
# If none of these strategies work for your deployment, you can define a custom strategy without forking Platform
# source by defining your Groovy-implemented IPersonAttributesFilter anywhere that can be referenced by a Spring
# pseudo-URL. If you define a file: URL, changes to the script will be picked up automatically without requiring
# an app server restart. E.g.:
#
#  environment.build.sso.personFilteringScript=file:/opt/sspconfig/MyPersonAttributesFilter.groovy
#
environment.build.sso.personFilteringScript=classpath:org/jasig/portal/portlets/lookup/NoOpPersonAttributesFilter.groovy

 

4 - Import Permissions for Watch Student Feature

After the SSP-Platform source has been pulled into the local repository, the following import will add the appropriate permissions for the Coach and Manager roles to enable the Watch Student feature.

Code Block
ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-770 data-import

 

5 - Import Permissions for Bulk Action Features

After the SSP-Platform source has been pulled into the local repository, the following import will add the appropriate permissions for the Coach, Manager and Administrator roles to execute Bulk Actions from the Caseload and Search Results

Code Block
ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-2086 data-import

 

6 - New permissions and functionality were created to remove the Main Tool from individual users or groups/role (added in v2.5.2)

The intent of this feature is to remove the display of protected information from users who should not have access.  For example, the application can be configured such that faculty members who do not need to view academic history for any student will not have the Main Tool available in the UI.  Instructions to manage the permissions are described in the User Guide. Before you'll be able to manage those permissions, though, you need to run the following command from within your SSP-Platform source code checkout (only necessary for an upgrade; fresh installs will execute this file automatically):

Code Block
titleImport New Permissions
SSP_CONFIGDIR=</path/to/your/config/dir> ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-5-2/SSP-2631 data-import

v2.6.0 JIRA Issues

Bugs

 

Improvements and New Features

...