I'm working with John Rocchio on the prototyping of a shopping cart to assist Dining Services. See the demo at, http://asg-dev2.ucsc.edu
Problem/Opportunity
The problem/opportunity can be defined as a process improvement. Dining Services has been using a PDF based form to allow students to order and take advantage of campus purchasing power. Essentially, an on-campus student may order a box of cereal and pick it up. A financial transaction takes place at the time of delivery.
In the current process, individuals download a PDF, fill out the PDF and email the PDF to Dining Services. Dining Services receives the PDF, updates their ordering and inventory. The student comes to pick up the order and makes a payment; cash, flexidollar, meal plan, credit card, etc.
Dining Services had proposed that they purchase a shopping cart service from a major vendor. Due to the timeline and the security requirements we'd have to meet for PCI compliance, we counter-proposed a potential solution.
Potential Solution
We've prototyped a vanilla Drupal installation with the Ubercart module. We created a product catalog and loaded some of the items displayed in the PDF form, taxonomy terms to help with information architecture and payment configurations.
We propose that anonymous users (campus IP domain restriction) would approach the online grocery, shop for items, create carts and place orders. Further, we propose no financial data transaction take place in this system, but rather it be thought of as a simple ordering system. As such, it's a fairly low security threshold to meet unless we need to centrally authenticate. That could be done using CruzID Blue or with some additional configuration of Shibboleth libraries, via CruzID Gold.
At the time we determine final requirements on authentication and security, we'd determine where the app needs to live; local servers or data center VM.
Process
Individuals placing orders would receive email receipts. Dining Services staff would have administrative privileges into the system to see orders, reports and have the ability to download into .csv or .xls any data they need to feed into other downstream systems. This is a potential area for additional automation.
Work Breakdown
We see the work of maintaining the product catalog work that would be performed by Dining Services staff. We see the server hosting, system and application administration work by ITS CRM staff in the prototyping phase. Should the requirements end up including a financial transaction, we'd probably recommend that Dining Services work through an RFP or select a vendor that can meet PCI compliance and handle the various internal currencies used by students (Flexidollars).
What's Next?
Dining Services needs to work with this prototype to fully understand what is possible using the proposed workflow and processes associated with managing an online product catalog. Any effort invested in this area will be re-used for any shopping cart they eventually select (Yahoo, Google, or proprietary). ITS needs to determine if the technical architecture is sufficient to meet the requirements for the prototype, develop a budget for any costs associated with this prototype and finalize the configuration of the shopping cart software.
Should Dining decide to proceed with this evaluation, ITS CRM will provide some basic Drupal training, accounts and instruction in how to configure and use the Ubercart modules.
Caveats and Provisos
This is all running on development boxes and services may be interrupted without prior notice. We try to hold off on reboots during the 8-5 window, but it happens sometimes.
Feedback module is intalled. Click the icon in the lower left footer to leave feedback for any page you're working on. This tells me where you were when you experienced a problem or had a question.
Update: Restricting by campus domain is more challenging than I thought it would be. The Aegir hostmaster does not allow for an .htaccess file per site. It may be that we can create a separate platform and override the platform.conf file to allow our own custom .htaccess with deny,allow directives. That'll take some work to configure and test. An alternative would be to force users to register (disallow anonymous content access). The downside here is that we're not planning to authenticate against any other systems, so we wouldn't know if we had a non-student trying to place an order. More thought is needed.
Reference on Users, Groups, Roles: http://www.packtpub.com/article/user-access-control-drupal-6