Test Banner Logins

It is often a source of confusion and frustration that some people can login to a service on Banner PROD but cannot login to the same service in Banner TEST. During a TEST database refresh, we take a number of steps that try to prevent accidental logins to the TEST database, so that people do not accidentally login to TEST and try to do work that they think is happening in PROD.

This article attempts to document the various ways that TEST logins are different from PROD logins, and what can be done to help a person login to TEST if necessary.

Person record

Firstly, the TEST database starts out as a snapshot of PROD as of a certain date. After that date, the PROD database continues to receive its regular updates; however, the TEST database is updated much less frequently. Therefore, an employee who was hired or a student who was admitted after the most recent refresh date will most likely not have a SPRIDEN record, let alone any other records in the TEST database. This will affect their ability to login, and their ability to use the PIN reset utility to change their PIN (since they do not actually have a PIN, and no biographical data to use for confirmation of their identity).

To resolve this issue, a database administrator or a developer may use the SPAIDEN or one of the other *IDEN forms to create the person record in TEST Banner. While the PIDM in TEST may not match what is in PROD, you can usually select the same Grizzly ID for the person as you enter their data.

If the person will be logging into TEST Banner, you will also need to enter an email address (see below).

Email address

Secondly, during a TEST database refresh, we delete the non-OAKU email addresses of everyone who does not have a GOBEACC record. Additionally, for everyone who does not have a GOBEACC record, we modify the OAKU email address by prepending "test." to the address (e.g. [email protected] becomes [email protected].

A few critical processes use the email address to modify other Banner data that affect logins:

  • GZPNACT - The GZPNACT process runs automatically once daily, and attempts to create GOBEACC and GURIDEN records for persons who have new Banner accounts. If the email address does not match the Banner ID, these records cannot be created.
  • GZRVPAC - The GZRVPAC process runs automatically every 5 minutes, and attempts to create or modify GOBTPAC and GOBUMAP records for persons who have been created in Banner. If the email address does not correspond with the actual email address, the GOBTPAC and GOBUMAP information will be incorrect.
    • GOBTPAC - The GOBTPAC_LDAP_USER column affects the user's ability to use the NetID to login to Self-Service Banner 8.x. It also may affect the user's ability to login to the TEST instance of MySAIL (Aaron, please confirm). The GOBTPAC_EXTERNAL_USER column affects the data transmitted to Ellucian Intelligent Learning Platform (ILP).
    • GOBUMAP - The GOBUMAP_UDC_ID column affects the user's ability to access Banner Admin Pages and Self-Service Banner 9.x apps.

The easiest way to correct this information is to use the GOAEMAL form to modify the user's OAKU email address to be the actual email address. The GZPNACT and GZRVPAC processes will correct the corresponding data the next time they are run. If necessary, you may submit those jobs manually. Check the output of those jobs and the GOBEACC, GURIDEN, GOBTPAC, and GOBUMAP data to confirm that the desired data changes actually occurred.

PIN matching

Thirdly, during a TEST database refresh, we randomize all PINs, and change the answer to the PIN hint question. This attempts to avoid the situation where a student who finds the TEST application's login page from logging in with their GrizzlyID and PIN to perform PROD work. There are two different ways to gain access to any Self-Service Banner account in TEST (for TESTING PURPOSES ONLY), provided that the service uses the GrizzlyID and PIN for authentication:

  • Database Administrators and developers may login to Banner Admin Pages and use the GOATPAD form to change the person's PIN to a known value.
  • Other Banner testers may use the answer to the PIN hint question to set a new PIN for the person whose ID they are using in TEST. The PIN hint answer is determined during the TEST database refresh process.
  • Other Banner testers may use the TEST PIN Reset utility page to change the person's PIN to a known value. The tester must know certain biographical information about the person whose PIN they are changing.

NetIDFourthly, Self-Service Banner applications that do not use sso.oakland.edu will check the user's LDAP attributes for an attribute named "ouEduPersonBannerDev". If the attribute is not set, or is set to "false", the user cannot login using their NetID and password. The following applications are affected:

  • SAIL (Self-Service Banner 8.x) - see $BANNER_HOME/oakmods/wtlweb/dbprocs/twbklog1.sql
  • Flexible Registration - see $BANNER_HOME/oakmods/flexreg/dbprocs/sfoklogn1.sql
  • Self-Service Banner 9 applications which are configured in their application's groovy configuration file to use "default" authentication instead of "cas" - see $BANNER_HOME/oakmods/general/dbprocs/gokauth1.sql. NOTE: In TEST, applications which would normally use CAS might be configured to use "default" instead, to facilitate testing.

To mitigate this issue:

  • Use the GrizzlyID and PIN instead. You may have to reset the PIN, as described above.
  • Open a ticket to request that the ouEduPersonBannerDev attribute be set for your NetID. Database Administrators may request this for any ID as needed; however, others may do this only for their own ID. At some point, we may wish to add this to an appropriate access request form.

DataAdminHowTo