BASIS Cardholder Management Techniques


BASIS administrators may manage their cardholder (user) populations manually or automatically.

BASIS Cardholder Management Techniques

Manual Cardholder Management

  1. Open the BASIS System Administration application:

    Start -> All Programs -> B.A.S.I.S. ET693 -> System Administration -> [login]

  2. From the menu, select Administration -> Cardholders....
  3. Click the Add button.
  4. Please note: If you know all the person's information: Full name, Person #, UB Card #, and Badge type, it is best to add everything at the time of creating the user. This way you do not need to wait until the next day to add any access levels. If the UB card # (last 8 digits) is added to the 'Badge' tab, access can be given immediately under the 'Access Levels' tab.
  5. The Last Name field is required. Assign the cardholder's last name to the Name (Last) field. It is best to add the first name too. These fields are case sensitive. The first character of the first and last name must be capitalized.
  6. Prepend a 0 (zero) to the cardholder's person number and assign it to the Person # field. This field was designed to hold a 9-digit Social Security Number (SSN) field. Our UB Person Numbers only have 8 digits. We tack a zero onto the front of the 8-digit Person # to make it 9 digits long.
  7. Click the OK button.
  8. If you know the UB card #, click on the 'Badge' tab and click the 'Add' button.
  9. Under the 'Badge' tab, fill in the UB card # (last 8 digits only) to the 'Badge ID' field.
  10. If not able to choose the 'Badge Type' under the previous 'Cardholder' tab (if greyed out), make sure the 'Badge Type' field is chosen in this area.
  11. Click the OK button.
  12. Click on the 'Access Levels' tab. Click on 'Modify' and assign the appropriate access levels. Must click on the door icon to the left of the description. This will add a red check mark to the access level.
  13. Click on the 'Activate Dates...' button if you want to specify a Deactivation Date. There is no need to specify an Activation Date. Access will begin immediately.
  14. Click the OK button twice.
  15. Best practice is to push the DB to the readers to ensure immediate access for the new user. Do so by following these instructions:
  16. Now the person that was added to the DB has immediate access to the door(s) assigned.
  17. If only the Full name and the Person# was added, the next time our automated cardholder population script runs, at 8:30 AM, the script will populate the remainder of the cardholder's personal information from institutional data. Then you'll be able to assign the cardholder's access levels by following Steps #12-14.

Automated Cardholder Management

If you would like to grant access to well-defined sets of cardholders, we can automatically set and renew their access level memberships. Follow this procedure:

  1. Who Gets Access? In Structured Query Language (SQL) or English, define the set of cardholders to whom you're granting access. Examples:
    1. Structured Query Language (SQL). In this example, select a constrained subset of Med School faculty and staff:
      SELECT DISTINCT b.principal
      FROM ubs_emp.active_employee_directory a
      INNER JOIN dce.person_number b ON (a.person_number = b.person_number)
      WHERE a.hierarchy like '0812%' AND
      ORDER BY b.principal; 
    2. English. Examples:
      "All Nursing 601 students"
      "All CSE graduate students"
      "All OT 599 students in the 'SJC' section"
      "All University Police"
      "All LIS administrative staff"
  2. Where Do They Get Access? Define the access level(s) to which the cardholders should be granted access. Examples:
    'Bell 314'
    'CIT - All Doors Always'
    'Dental Medicine Fac/Staff-Foster'
    'Jacobs 324 7-11pm'
    'Allen Hall Campus Police'
  3. Email CSE. Send the populations and access levels (defined in 1. and 2., above) to
  4. Confirmation. CSE sends you confirmation that your new rule is added. We'll add the query to our Perl script that polls UB institutional data and pushes it into BASIS at 8:15 AM. The script works by extending active cardholders' BASIS access levels' expiration datetime values by another day every morning.

    In the BASIS system administration interface, if you query a cardholder whose access is set by an automated rule, you should see that her access levels expire 2-3 weeks from today. When you query her account tomorrow, her access levels will expire 2-3 weeks from tomorrow. When cardholders leave UB, they are flagged as 'inactive' in UB institutional data. When a cardholder is flagged 'inactive' in UB institutional data, our queries fail to select them, so we stop extending their access level expiration datetime values. That is how departed cardholders automatically lose their access rights 2-3 weeks after leaving UB.