CV Entry Application¶
I talked with Marc over lunch today about the small application request you made this morning.
Below is our understanding and conclusion about this project.
Project reviews require all project participants to submit CV information. This information is
usually collected in an ad hoc, nonuniform way, resulting in a collection of information that
cannot be reused. The information typically requires quite a lot of manipulation to massage it into
a common format due to the large variety of document preparation tools.
The upcoming Proton Review requires this CV information and the division would like
to collect it in a more structured and uniform way, so that it may be rendered as required by the
Produce a simple web application for participating scientists to enter CV information. Use the
entered information to produce the CV report needed for the review.
- a user must first register using a badge number to obtain a login
- a user must login before editing or creating records
- a user can only create, edit, or view record he owns
- only specially assigned logins will be able to view or access the collected information
- the application will run on our group server
- SSL will not be needed when information is added or edited or accessed
- Our application can send out email to a user attempting to obtain a login.
- This is an application for entering data into a database, not for producing the report.
- any lab employee will be able to enter CV information
This will be a simple, quickly produced application. Whatever is developed can be extended and is
not meant to be disposed of.
Information to be entered about the user
- Fermi badge ID
- person's last and first name (separate text entry fields)
The four main categories of information to be entered are
- Selected professional activities
- Selected publications
How do you want the data for each of the things listed above to be entered?
Should each line entered be an unformatted blob of text?
Suggestions for entry of data in each line:
- education - institute, date attended, degree
- employment - place, title, date employed
- activities - one text entry box per activity
- publications - authors, title, journal volume page, date, other information
An template or example should be included on pages that require text entry so that
the user knows what the information should look like. This applies to the
education, employment, and activities sections.
A user can enter as much information as he wants about himself. Limits are imposed for
review output only.
Limits for review output:
- 8 publications
- 4 employment entries
- 4 activities
Spires should be queried to automatically get a list of publications.
The CNAS database has employee names, IDs, and email and should be queried for information. Matt Arena is the contact.
This is the database that is queried by the Fermi phone book application.
The users must be able to select the publications, activities, and employment they want included in a particular review,
and also order them.
The application must allow a user to add himself to a particular review, and then select the information that will be
present for that review.
Output format will be PDF, for all participants in a review, or for a single person.
A user must be able to enter up to one page of free format text about himself. (is this really necessary?)
Should Spires be queried to find publications and present them in a common way? yes, if it is easy enough to do. Vicky ruled no.
Do publications and professional activities need to be associated or tagged with a particular review? yes
Is the security model model good enough? yes Vicky ruled no; we have to use KCA authentication.
What is the longevity of this project and its enhancement / support burden? unknown, but claim is short for our group
What about commonality amongst like names for institutes, dates, journal names, etc.? Is this necessary? do not worry about this
What sort of output selection is necessary? By review? by review, for a single person, PDF Vicky also mentions XML and spreadsheet output.
We assume all the questions above have been answered.
- Fast (< 1/2 day) production of prototype, to get a "go/no-go" decision, based on whether the appearance and functionality of a simple Rails application is sufficient.
- If the decision is to proceed, 3-4 days to produce the agreed-upon functionality (the addition of KCA requirement increased this estimate from 2 days).
- We assume that Bob will be available (reachable via phone, at least) to answer functionality questions during the development.
The biggest risks are the Spires and CNAS database access and queries.
- New People are never added through the web application. The list of allowed users is to be imported directly to the database; we acquire names, badge numbers, kerberos principals, and email addresses in this importation step.
- Only recognized People can interact with the web application. Verification is to be done using KCA. We assume that when a browser with a loaded KCA contacts a web server that some identifying information is passed along to the rails application. For now, we are assuming this is the kerberos principal (the name).
- The various screens for adding new information (educational history, employment history, professional activities, publications) all rely on the session object (?) sending along the kerberos principal. Each will use the kerberos principal to look up the Person with whom the information being added is to be associated.