UNC's mainframe FRS (based on network database model) feeds info into the Departmental Accounting System (DAS, aka InDEPTh) which is an Oracle database.
Ed has arranged that they automatically generate two tables for CPC. The two tables would be flushed and regenerated every night, populated with the data for the current fiscal year (begins July 1). This is similar to what the business school has negotiated.
The two tables apparently represent "transaction" and "cost code" objects in a one-to-many relationship (a transaction can have one or more cost codes associated with it). However there apparently no primary key for the transaction table, which complicates our ability to differentiate previously imported transactions from new transactions each night. (Also raises questions about how the transaction and cost code tables actually relate).
Ed needs a way to get the new data from these two tables, make sense of it, extract everything except FRS's personnel projections, and import it into CPC's mysql database. Ed is giving this project to me. Measure would then have to extract the relevant data from the CPC expense tables for use in our system.
WebGUI tracks users and their authentication method (either Kerberos, aka Onyen, or WebGUI, aka local). Ed adopted/modified some Perl code to communicate with UNC's Kerberos server and authenticate UNC users. Non-UNC users would be authenticated using WebGUI by comparing MD5 hashes of passwords.
Database design note. User authentication consisted of two tables, one called "users" with a userid column and an authmethod column. The "authentication" table did not appear to have a primary key, and consisted of a userid column, an auth method column, and a generic value column. This allows the database to capture multiple name value pairs for each user's possible authentication method without having to change the database schema.
WebGUI also tracked group information, and provides interfaces for modifying those groups.
Ed mentioned that he saw WebGUI as a two year long investment, and he's already one year in. I continue to hesitate Measure going down the WebGUI path, but I may not have enough sway to prevent that from happening.
This is my current area of focus/consternation because of the lack of any high-level design schematics of the fiscal system I'm currently implementing for work/masters project. Chatted with Ed that Measure needs a Web Application (several actually) of which the fiscal component is a primary part, not just a content management system.
I feel we really need to move in a more object-oriented direction, towards web application frameworks like Cocoon, etc. Complexity is a barrier here, and the more I think about adopting a solution other than straight-up PHP for the next 2-3 month, the more I have second thoughts.
We chatted about using UML to document our systems.
I emphasized that the future incarnation of we presently call "the database"---which includes finances, activities, publications and requests, and personnel and contacts---should be web accessible and "administerable" in phase II. From this perspective the database will become the website - or alternatively, the website will absorb the database.
Whether or not this is the path ultimately decided upon, it has implications for my role within Measure and for the responsibilities assigned to Ed and the web developer CPC is currently recruiting for Measure.
Ed seemed amenable to the idea that Measure may continue to require custom built applications (or plugins) that differ from what the CPC web team is offering to the smaller CPC projects--in light of the idea that Measure's website assumes the role of Measure's databases.
After the meeting Ed and I discussed the caveat that if Measure goes the custom route (which it almost certainly must), then further down the road we need to decide how to handle Measure researchers who may want the functionality of Measure's web application for non-Measure, CPC projects. Similiarly, we may have to contend with CPC researchers who come over to Measure looking for the functionality that has been available via CPC's web application system.
Melody discussed the idea of a web-based task force in order to inform the future directions of the website/intranet/database. I feel this process would be best facilitated by a blueprint (or functional specification) that describes in concrete detail exactly what the website will do. I've begun work on this and will have Ed, Phill, Melody, etc vet it prior to any task force meetings.
Melody suggested that my phase II role may have been largely conceived in terms of support to the researcher's database needs (e.g. PIMS). I would like to continue to assist the PIMS effort, but if given a choice, I would more like to take a leading role in the formation of Measure's new interactive, collaborative, database-driven, web application information system (acronym yet to be decided upon).