1. Introduction

The goal of this project is to create a OSS(Open Source Software) shopping cart that’ll incorporate grant number purchases. Currently, book keepers are manually inputting purchase information and grant numbers. With this OSS shopping cart, the strenuous manual labor can be handled automatically and efficiently.

User Definition Requirements - This section will describe the major features of the shopping cart system. It was written in a non-technical fashion where most people can understand the content.
Constraints - This section contains the technical constraints of this shopping cart system.
System Definition Requirements - This section describes what’s needed for the shopping cart system in more specific and technical terms.
Acceptance Test Plan - Scenarios and test approaches are described here.
Implementation Phases - This section contains our implementation of the system. Tutorials, installation, and guides can be found here.
Process - This section contains a guide on how to use the shopping cart system once it has been completed and implemented.
Future Directions and Expected Changes - This section contains information about features that can be implemented in the future if requested.
Glossary - This section contains terms used throughout the document.

2. User Definition Requirements

The key features of this OSS shopping cart are:
- Processing grant number purchases
- Software purchases is handled electronically where customer can download the product from the OSS shopping cart
- Data saved into a form that can be imported into a spreadsheet
- Automatically handle license processing upon purchase with specified hostgroup

The OSS shopping cart deals with three major entities:
- Lab Principal Investigators
- Departmental Book keepers
- Users of the Software(in other words, the customer buying the software with a grant number)

3. Constraints

Currently, the OSS shopping cart does not store information about host groups and grant numbers. We also don’t want to modify the OSS shopping cart internally. As a result, we’ll need to store the grant number and host group information elsewhere and connect/relate the information with the OSS shopping cart.

4. System Definition Requirements

The system will require:
- A open source software shopping cart
- Internal and external databases that will be linked through a relational key
- Security login system
- A preregistration form for users to input their project information

4.1. OSS Shopping Cart

The OSS Shopping Cart is needed to provide the customers with a user interface that’ll allow them to select items and purchase with ease. The best thing about an OSS shopping cart is that it’s free.

4.2. Databases

The internal database stores information for the OSS software shopping cart. The information within this database mostly deals with products to display, shopping history, payment methods, etc. The external database stores information with regards to the preregistration form. Information such as grant numbers, project names, and host groups are stored in this database.

4.3. Preregistration Form

The preregistration form is a very important component of our system. Here, users will fill out contact and project information that’ll be stored onto the external database. There are conditions that need to be met for a successful preregistration. These conditions can be found at the "Process" section of this document.

4.4. Security Login System

To prevent malicious activities, a security login system is needed to preregister the user. It’ll prevent users from inputting false information during the preregistration process. UCI’s login system is an ideal approach.

5. Acceptance Test Plan

5.1. Scenario 1

During the preregistration process, the user must fill out mandatory information depending on who they are. If the user selects to be either a Lab Principal Investigator or Departmental Bookkeeper, then they only have to fill out the mandatory personal information. If the user is a buyer of the software, then they have to fill out both mandatory project and personal information. The Lab Principal Investigator and Departmental Bookkeeper do not have to fill out project information because they are not the one buying the software. The script must check if all mandatory fields are filled with a correct format, otherwise it will not allow the user to proceed beyond the preregistration.

5.2. Scenario 2

After the preregistration process, the user can buy products on the main site with a preregistered grant number. However, there is a time limit in which the user can purchase with the preregistered grant number. If the user purchases with a preregistered grant number within the time limit, then the preregistered grant number will continuously display during the payment process. If it’s not within the time limit, then the preregistered grant number will not display at all. The payment module scripts must be configured for an invalid grant number purchase(e.g. purchase exceeds time limit).

6. Implementation Phases

Information about the implementation of our system can be found here.

6.1. OSS Shopping Cart

Our system implements the Prestashop OSS shopping cart. (insert more info about why we chose it over other software). The programming languages in our implementation used are Python and PHP.

6.2. Databases

Prestashop uses MySQL as it’s database engine. Thus, the external and internal database are based off MySQL.

6.2.1. presta12

Presta12 is the internal/main database for the Prestashop. This database is required to run Prestashop. It stores information such as products, shopping history, personal information, payment methods, etc. Remember that this database does NOT store project information such as grant numbers, project name, and host groups.

6.2.2. shopform

Shopform is the external database used to share project information with presta12. Project information can be found here such as grant numbers, project names, and host groups. The database also stores personal information for future purchases.

Personal information between presta12 and shopform MUST BE IDENTICAL to relate the two databases.

6.3. Security Login System

Our system implements UCI’s WebAuth System. Using the WebAuth system, users will have to login with their UCINetID. This provides a sense of security in which the person who is preregistering is affilliated with UCI. (I need to insert documentation as to how I approached this programmatically.)

6.3.1. Files

prestalogin.cgi

6.3.2. Process

After successfully logging in through UCI’s WebAuth System, WebAuth will proceed to redirect to the specified link. For our system, the specified link is a script that will process the preregistration form. Here’s how the link looks like:

https://login.uci.edu/ucinetid/webauth?return_url=http://moo.nac.uci.edu/cgi-bin/prestaform/prestalogin.cgi

http://moo.nac.uci.edu/cgi-bin/prestaform/prestalogin.cgi is the script that will process our preregistration form. To process the preregistration form, we’ll need the UCINetID inputted during the login process. WebAuth stores this information inside a cookie. I simply retrieved the cookie and used an online WebAuth script to extract information from the cookie.

The online WebAuth script I used is:
https://login.uci.edu/ucinetid/webauth_check?ucinetid_auth=INSERTCOOKIESTRINGHERE

Here’s the coding:

prestalogin.cgi

...
#Get all cookies
cookie_string = os.environ.get('HTTP_COOKIE')
uciCookie = ""
list_of_cookies = cookie_string.split(";")
for i in list_of_cookies:
        entry = i.split("=")
        #Save if it's the  UCI cookie
        if entry[0] == "ucinetid_auth":
                uciCookie = entry[1]

#Send uci cookie to online webauth script to extract information
filehandle = urllib.urlopen("https://login.uci.edu/ucinetid/webauth_check?ucinetid_auth="+uciCookie)
cookieInfo = []

for lines in filehandle.readlines():
        cookieInfo.append(lines)
#Retrieve and save the UCINetID for the preregistration process
userid = cookieInfo[0].split('=')[1].strip()
...

6.4. Preregistration Form

This process occurs after logging in through UCI’s WebAuth System. The WebAuth System will then redirect to an internal script that’ll process a preregistration form. Depending if the user has registered himself/herself before, the script will either process a populated or blank preregistration form. To make a grant number purchase, the customer must first fill out the preregistration form where they’ll input a grant number, host group, and project name. Currently, the system has set a 1 hour time limit to make purchases with a preregistered grant number. The reason for this is because the timeframe between preregistering and purchasing the product is the only available key we can use to connect orders and project information.

6.4.1. Form Model

form.html

6.4.2. Files

prestaform.cgi

6.4.3. Process

This script is basically a bunch of if, else, and print statements. It checks conditions with if and else then prints html code to process the preregistration form. The focus of this section will be about what happens after a successful registration.

6.5. Conditions for Preregistration

The conditions that must be met can be found at the "Process" section of this document.

6.6. Purchasing

If the customer hasn’t registered himself/herself in prestashop, then they’ll have to register with identical information used in the preregistration form. The reason as to why the user has to register again is because the preregistration process is not internally related to prestashop. Identical information must be used since the two databases will be querying against each other and compare relational information. In our implementation, the relational keys to relate shopform and presta12 are email and datetime. Once the customer has successfully registered in both the preregistration form and prestashop, they can proceed to add products into the cart and checkout. Upon checkout, the customer will be able to select a purchasing with preregistered grant number module. If the customer is still within the time frame, their preregistered grant number will be displayed and the purchase can be made.

6.6.1. Files

6.6.2. Process

6.7. License Process Handling

Currently, this is not implemented in our system. It’s basically a script that’ll add hosts(retrieved from a preregistered host group) onto a license server. More information will be added upon request.

6.8. Accessing Databases and SQL Queries

(Separate Document)

6.9. Spreadsheet and Table Information

(Explain)

7. Process

Here is a typical and successful purchase walkthrough:

7.1. Preregistration

Users will first log in through UCI’s WebAuth System here. Once they’ve logged in, a preregistration form will be processed.

7.1.1. Conditions

Here are the conditions that must be followed:

Step 1:
The Departmental Bookkeeper must first register himself/herself in the preregistration form so that the Lab Principal Investigator and User of the Software can
select him/her upon registering.

Step 2:
Next, the Lab Principal Investigator must register himself/herself in the preregistration form so that the User of the Software can select him/her upon registering.

Step 3:
Lastly, the User of the Software will now be able to select a Lab Principal Investigator and Departmental Bookkeeper along with filling out project information.
The information is then stored into the database.

7.2. Main Page

Upon successful registration, the user should be redirected to our prestashop’s main page which can be found here. The user must register themselves with identical information to the preregistration form if they haven’t done so yet. Once they’ve logged into the main page, they have one hour prior to when they preregistered to make their grant number purchases. After checking out and selecting the grant number purchase, user’s will be able to electronically download their software by accessing their shopping history. This information is accessed by clicking "My Orders" under the "My Account" tab.

8. Future Directions and Expected Changes

8.1. License Process Handling

(Harry should fill this section out)

9. Glossary

10. Auto-Generate

Here you’ll find a script that does all the joining and printing already. You can either find a table printed format or tab delimited format here for your excel spreadsheet.
Auto-Generate Table
Auto-Generate Spreadsheet