This page and any within it will describe the method and structure of how our business uses the ParaDocs product to match our organization.

Ex: Making a group called EDI and a group/track within it called DE.

Any applicants that apply to the wrong program and are already on ParaDocs should be dealt with by:

1. change program on SIS if needed
2. printing out their existing documents, or checking that the documents are in their hard file
3. deleting their old workflow AND documents in ParaDocs (request IT Specialist to do it)
4. re-scan and profile all documents from the start

Simply re-workflowing their existing documents in ParaDocs may not work. This is because the documents have already been coded to be EDA (example) and are still associated with EDA instead of what you want to change them to.

Changing an applicants program is also not easy to do on the ‘Paradocs Tables’ method of editing raw data. Do not use the ‘Paradocs Tables’ database in attempts to completely alter an applicants program. Ex: applicant applied to EDA and they really should have applied to EDI DE.

The ‘Paradocs Tables’ database is a custom UMBC Graduate School database created in Microsoft Access for use by employees of the Graduate School. It has some of its own data, but most of it is linked (via ODBC) to the raw data tables in use on the live ParaDocs system.

The ‘Paradocs Tables’ database was originally meant for just looking at data. It should not be used to alter data at all, although I believe that some simple editing of data is ok. We have successfully used it to alter simple data.

In ‘Paradocs Tables’ Access database:

• Ok:
  1. Change Terms (Deferal)
  2. Change SSN (maybe one SSN is messed up, not if all are messed up)
  3. Change Name (maybe one name is mispelt, not if all are mispelt)
  4. Change Path (to match path of others)

• Not Ok:
  1. Change Department (person applied to wrong department - Delete and rescan)
  2. Change DocType (wrong documents type entered on scanning - Delete and rescan)
  3. Change Objective (person changing from MS to PHD - Delete and rescan)

A built-in authentication system is supplied with ParaDocs. It most likely uses some internal php authentication method that refers to the user data held in ParaDocs database tables. It requires a User Name and Password. Its login page is located here: http://gsdocs.umbc.edu/paradocs4/auth.php

Individual user accounts are created inside of ParaDocs Online Admin screen by UMBC ParaDocs Administrators. Passwords are assigned, most UMBC users do not know their true ParaDocs passwords.

DaySpring correction appreciated

The majority of users gain access to ParaDocs via MyUMBC - http://www.umbc.edu/oit/iss/syscore/wiki/MyUMBC . MyUMBC is a centralized web portal for campus users to access many different University electronic resources.

The users first goto http://my.umbc.edu and authenticate to MyUMBC. There is a link that is within the MyUMBC portal that forwards them onto the ParaDocs system. The link is located inside of the ‘Administration’ tab and then under the ‘Admin Rights’ heading as ‘Graduate School Imaging System (ParaDocs)‘.

• The above link somehow automatically bypasses ParaDocs authentication, as long as the user name on ParaDocs and MyUMBC are the same.
• The link goes to: http://gsdocs.umbc.edu/cgi-bin/web-auth.pl → https://webauth.umbc.edu/umbcLogin?return_uri=http%3A%2F%2Fgsdocs.umbc.edu%2Fcgi-bin%2Fweb-auth.pl%0A&Service=gsimage → http://gsdocs.umbc.edu/para-docs/pd_auth.php → http://gsdocs.umbc.edu/paradocs4/auth_group.php → http://gsdocs.umbc.edu/paradocs4/iframe_win.php

WebAuth is UMBCs homegrown authentication mechanism that we use to enter secured sites and services such as myUMBC and webmail. Because paradocs entry is done through myUMBC, there is some interaction with webAuth.

Ip verification is a feature of webauth. Below is a description of it by webauths creator:

The IP verification stuff in WebAuth is another level of security to help
fight against attacks where someone somehow gets access to your cookie stash,
then uses the cookie from another system to impersonate you and get access
to the system.  In order for it to work, however, the IP that you're coming
from when hitting the webauth.umbc.edu server has to the the same IP you're
coming from when you hit the service (such as paradocs.)
When users come through the VPN, access to "some" ips goes through the VPN's
IP address, where as most others go directly to the machine from the IP.
When they decided to put Paradox behind the VPN, they also made traffic to
webauth for those users go behind the VPN.

— Rob Banz

A small amount of WebAuth code is implemented on the ParaDocs server. It looks something like this:

<somethingsomething>->read_ticket( $foo, $bar )

With IP verification turned off, it looks something like this:

<somethingsomething>→read_ticket( $foo, $bar, 0 )

<somethingsomething>->read_ticket( undef, undef, 0 )

Our webauth perl code is located on gsdocs.umbc.edu at:

/var/www/cgi-bin/web-auth.pl

As of 10/3/2006, the paradocs server have IP verification turned off. This is because myUMBC is not behind the VPN. With VPN turned on at a client, the IP will change when going from myUMBC to paradocs. The webauth code will detect the change in IP and think that someone is trying to hack authentication. This will result in not being able to login.

Nick yeates and Eric Ewen discussed the below on 9/14/2005:

Back in 9/04 or so, changes were made to separate EDI and EDI_DE. The DE stands for the ESOL track within the EDI program. This change occurred because the process of workflow routing from EDI to EDI_DE was cumbersome, and the coordinator was not able to successfully keep up with both tracks. The DE track users were not getting their applicants.

Fast forward to now, the program EDI_DE (more formally EDI program with DE track) had a problem with viewing documents within workflows. They could see only a limited number of documents from their numerous workflows.

Ends up being that documents falling into the EDI_DE category have most likely been being mislabeled for quite a time by scanners. The EDI_DE administrative users had to be included in the EDI group as well as the normal EDI_DE and EDI_DE_ADMIN groups.

Putting the users back in the EDI group fixed their viewing status but there is possibly a bigger picture problem of wanting to truly seperate EDI_DE, EDI_DT, EDI_DF and EDI. It is confusing for scanners to choose EDI_DT over simply EDI. No other programs have the tracks seperate, so it does not make much logical sense.

User request:

Q: “Couldn’t there be a link attached to these [automatic workflow notification] emails to take us right to paradox?”

A: This type of functionality would be extremely powerful for users, and increase system use. I would love to see the idea implemented.

At first glance I do not beleive that it is doable for free, and beleive that it would introduce security concerns that would take time to assess. You are being authenticated (typing a password), each time you enter into the ParaDocs system (via MyUMBC, which takes your password). A link cannot securely bring you into a password secure site automatically. For example: there is no direct link to your myUMBC transcript, because you first have to log in to acccess it.

If you were already logged into ParaDocs and had a window logged into ParaDocs in the background, a link like this would more than likely work. My guess though, is that most users do not keep ParaDocs open at all times of the day.

Another implementation idea is that it provides a link to the login page, where you type user and pass in. An ideal way to do it would be via the UMBC WebAuth - http://www.umbc.edu/oit/iss/syscore/wiki/WebAuth , so that clicking through MyUMBC were not required.

Q: How does OIT receive notices for low HDD space on the ParaDocs server? I am guessing that OIT receive other similar notices?

A: OIT uses a program/package named nagios which is freely available at nagios.org. OIT uses this package to monitor dozens of systems on campus. Basically, a client is installed on the server and the nagios server can then contact the machine and get the appropriate info.

Batch printing allows multiple documents in ParaDocs to be printed at once to a networked printer. This allows departments to print many documents at once to a pre-specified department printer.

Note: Printer must already be on the campus AD network

1. Get printer information
   Example:
   • AD Name: GRAD_HP4650
   • IP: 130.85.0.1
   • Model: HP Color LaserJet 4650 PCL 6
2. Create new printer directory (optional)
   • (optional), OIT can do this step if needed
   • at the location \\gsdocs.umbc.edu\batch_print\ create a new directory for the printer
   • name it something similar to the existant name of the printer
   • make sure that the file permissions are set to octal 777 (chmod 777 <foldername>) and that the groupid for the file is ipost and the owner is paradocs (chown ipost:paradocs <foldername>)
3. Send request to helpdesk
   • request that the new printer be added to the batch print pro software
   • make sure to be specific that this task needs to be assigned to the Business Services Group within OIT

A seperate windows based server sitting in OITs data center is doing this batch printing. A piece of third party software called Batch Print Pro watches some Samba directories and prints any documents that are placed into those directories.

Below is the directory listing of the samba share on the above mentioned windows print server.

 Volume in drive X is batch_print
 Volume Serial Number is 0A38-4F0A
 
 Directory of X:\
 
03/31/2006  11:31a      <DIR>          .
02/03/2005  12:49p      <DIR>          ..
02/27/2006  03:01p      <DIR>          PSYC
05/09/2006  02:14p      <DIR>          CMSC          130.85.94.207
03/19/2003  05:58p      <DIR>          PEOPXEROX
04/03/2006  02:12p      <DIR>          GRADTEK850DP
04/15/2003  05:02p      <DIR>          CHEM
01/27/2006  11:39a      <DIR>          BIOL
12/01/2003  01:51p      <DIR>          SOCI
10/15/2005  10:30a      <DIR>          Test
07/12/2004  04:28p      <DIR>          INCC
12/13/2005  03:37p      <DIR>          EDUC
01/27/2006  11:40a      <DIR>          BIOL2
05/08/2006  03:10p      <DIR>          GRAD_HP4650
               0 File(s)              0 bytes

Alternate names: Sweeper, Crossover, importing

The ParaDocs portion of the UMBC Admissions system needs to refer to SIS applicant data for many reasons. The basic solution is to pull the data from UMBCs existing Student Information System (SIS). Below are some examples:

• There needs to be an existing applicant record to allow documents for an applicant to be scanned. The ParaDocs scanner application has the user type in a SSN, which then tries to find the applicant and its subsequent attached data. If it does find the applicant, it automatically fills existing data in (program, year, track, sex, etc). This cross-reference of data has to exist somewhere and it has to be consistantly updated.
• Applicant data such as their enrollment/decision status, or name is altered on SIS and the changes need to propogate over to paradocs.

UMBC gathers the needed data and places it into a single table (possibly a view?) called T_IMPORT on the UMBC Oracle Shadow SIS. The data in the SIS shadow table is pulled over into a raw-text .sql file on the paradocs machine, in the format of SQL DML commands (INSERT commands). ( possible data exposure?)

Next, the ParaDocs machine imports the data from the .sql file into its own T_IMPORT table, essentially making a local copy of the SIS Shadow table. Finnally, some php code loops through each applicant in the local T_IMPORT table and updates fields that are different in the ParaDocs FAT table. The FAT table is ParDocs’s main data table.

Most of this is linked together by automation from multiple cron jobs on the ParaDocs server, located at /etc/cron.d/umbcsweeper . The cron jobs are timed to run at intervals that are slightly after each prior step 1).

Sometimes the crossover does not behave. The t-import table may be empty, certain processes will take a long time to finish, etc. In order to determine what is going on amidst the MANY things that happen within the crossover, you must audit or watch them somehow. Below are some ways that this can be done, and are currently being done:

1. Cron Auto Emailing - cron sends emails of the output to the root users mail box by default. You can check this mail box by using the mutt mail viewer. See more details on mutt here
2. Output Redirection - The actual crontab file umbcsweeper has been modified to send each run commands output to a local file. For exampple, at the end of each cron command, there may be a > ora2pg.err.out which means the standard output is sent to that file. If there is a 2> blah.err.out, it means the standard error output is sent to that file. Some of the processses have their output come out in different manners
3. Output emailing - There is one step that is solely on the side of UMBC, the very first step (see below). This has been setup in the past by OITs DBA to have its cron command to output its standard error to email. This is done by postfixing the cron command with “2>&1 | mail -s “Daily PARADOCS Load on seven” nyeates1@umbc.edu”

1. Since two seperate servers will be running two seperate automating jobs, how will the paradocs server know when the table has been created and to go about pulling in the data?
   • By running the two jobs at sufficiently different times
   • : This may be causing problems when any of the systems are under heavy use. If one process does not finish before another starts, the entire crossover may not work.
2. What is a ballpark figure on how long it will take the UMBC server to create this new table each time the cron runs? 30 second? 10 minutes? 40 minutes?
   • It takes about 3 minutes for the job to run to load the data into a UMBC version of T_IMPORT. More time (8 minutes?) should be given between the two proccesses.
   • need to do more precise study of this; possibly via emailing cron jobs to an email address, which cron supports, but is difficult to implement.

OIT Business Systems provides a cron job that runs for ~10 minutes, at:

• 6:00 am
• 12:00 pm
• 4:00 pm

This script will gather the needed data from various SIS Shadow database tables and drop the data into a seperate table of it’s own.

Is this done by a view now, instead of an actual process?

Dayspring has created a cron job that copies a single SIS Shadow view to a local .sql file (full of SQL INSERT commands) on the ParaDocs server, at:

• 6:10 am
• 12:10 pm
• 4:10 pm

The UMBC ParaDocs server will use a specially created UMBC Oracle account to allow an ODBC connection to access the SIS shadow database for that one single table (or view?). DaySpring is assigned it’s own login to the SIS Shadow database, but only has access to the single view.

DaySpring has created a cron job that runs the script timportupdate.sh . This script places the imported SIS Shadow data (from .sql files) into the local postgres T_IMPORT table. It happens at:

• 6:15 am
• 12:15 pm
• 4:15 pm

DaySpring has created a cron job that runs a php file /var/paradocs/nps-1.0/umbc_sweeper.php . Not absolutely sure what this code does, need to review code. This code changes the paradocs fat table to be synchronized with the t_import table. Because the T_IMPORT table already has the most up to date SIS data (as long as the T_IMPORT update above succeeded), the paradocs database (FAT is the main data table) is updated with particular data attributes in the local T_IMPORT table. This occurs at:

• 6:20 am
• 12:20 pm
• 4:20 pm

This part of the process takes the most time. A guesstimate of how long it takes is 20-45 minutes.

Documents in ParaDocs have a profile field (a column) that is labeled “Status”. See picture below.

The status field is totally different and seperate from workflows or workflow tasks. The status field is only on Application documents, not workflows. See documents_vs._workflows for details on the difference between the two.

In UMBCs implementation of ParaDocs, this Status column holds the decision status of the applicant. There are a limited number of different status’s which come from our SIS database and are defined by the Graduate Schools business processes.

Below is a table listing the current status possibilities:

A decision is made by the department, which they then physically Reccommend to the Graduate School (ussually by fax or email). The departments reccomendation is not the final decision. It is just a reccommendation to the Graduate School.

A decision is made by the Graduate School and the decision is put into SIS (such as Admit, Deny, Admit Pending, or Withdraw) by the Graduate School staff. A nightly process then updates the status field in Paradocs to the appropriate corresponding status like GS-Admit, or GS-Deny. This update is done every night. If the status field is changed in ParaDocs, it will revert back overnight to what SIS says that the Status should be.

Up until that decision is made, the department coordinators have the ability to manually update the status to RFR “ready for review”, Recommend Admit, recommend deny (or technically, whatever they want). Updating this status field before a decision is made in SIS may help the department coordinators and reviewers know exactly where the applicant is in the admissions process.

Now if the status is GS-Admit because a decision has been made in SIS, and for whatever reason the coordinator decides to update this to Recommend Admit in Paradocs, it should get updated back to GS-Admit during the nightly process.

There is an oracle view (probably referenced via local postgres table, T_IMPORT, the same table used for everything else SIS related) of SIS that is used to see which applicants have status data in SIS. Dayspring wrote the custom nightly sync process, sweeper, to do this update.

Automatic emails can be sent out when certain events occur, such as a document first coming into the ‘Assess for completness task’. Automatic emailing is not custom on ParaDocs, it is offered standard.

UMBC had the format of the auto emails changed for security and readability. The custom look is:

Subject: STUART is at task Assess for Completeness in EHS Application queue
Body: STUART is at task Assess for Completeness in EHS Application queue

There is a script or php code execution that constantly runs and occasionally checks that all custom and standard services are running. It may also restart a service if it is not running.

Little information on this is known at the moment. Jeremy Brenner implemented this after a few services (the posting services) continually were found not running for one reason or another.

Grouping options was edited to have slightly different functionality from standard.

1. Confirm boxes were removed from javascript code at the location: /var/www/html/paradocs-4.1/group_options.php
2. 2 seperate forms were created on page that used to have only one form. See this to-do list entry:
   • Grouping options assumes the wrong form submission when you hit the ENTER key. On the third frame where you select either to ‘Add Document to Existing SSN’ or ‘Start a new SSN Process’. If you are in the ‘start a new ssn process’ and hit the enter key after data input, the form for the other choice apparently gets run, causeing the workflow to not be created correctly.
     • html code corrected by Nick Yeates. There was originally only one form for two submission buttons that have different effects. Now there are 2 seperate html forms which elemenated the effect above. In the PHP, there is actually what looks like 3 forms, but it is because there is a giant IF that has 2 versions of the code for different circumstances.