Database Report Feb 2006

The Ghad project for administering group applicants is near deployment (expected 2005-06-16) Following this a half-dozen or so issues with rhadam will be dealt with. This should be completed by early next week at the latest.

The naming for the database has developed haphazardly, and cairo belongs to a library that is listed among debian repositories so a name collision is quite possible. We need a re-think about naming, not so much for the database, which does not need a name now I think about it, but we need a range of names for the various interfaces to the database.

The interfaces are (or will be)

The main interface for processing individual recipients and the machines they are given (currently called rhadam)
A more specialised interface for group applications (currently ghad)
An interface for generating reports and statistics
An interface for recording personnel and activity
An interface for scheduling and rostering.
An interface for inventory control (eventually)

This list need not be considered final or set. They should have names indicating the functions involved.

There were some informal discussions with Rob a while ago about inventory data management and I placed some thoughts on the matter on the mailing list prior to this.

If possible, a meeting to settle the main outline of an approach to the inventory issue would be helpful. This should happen as soon as possible, as there is no chance of starting coding without a reasonably clear plan.

Owen Courtis

Database Priorities 2006

Kylie and Jan had informal discussions about the priorities for the database The priorities were seen to be:

Ability to edit current information and fix errors on the fly
Group applications interface
User Support History
Inbuilt error reporting feature (nice but email will do for now)

Owen might care to list all the feature requests on his list, so these can also be added to a priority list. The issue of backup was also raised. What is the current practice here?

Database Report 2006-02-13

Item 1 of Kylie and Jans' Priorities 2006 has been implemented. From the "Look up" tab of Rhadam, individual fields in the table can be updated by right-clicking on them. After the editing is done, the user saves the update by pressing the key, then responds to a dialog to confirm the edit. Not every field is editable at this stage, however.

Re item 2 of the same, the group applications interface ( Ghad ) I expect to have deployed by the time of Tuesday's meeting.

Re item 3, Royce Ausburn, a new volunteer has developed a "Knowledge base" system to be used (in part at least ) to assist persons providing support. It has been agreed that the data storage involved will be located on the CBV "sql" server. As the support giver will have the KB on line while dealing with the client questions arise as to how to relate the use of the KB to the individual customer, the effectiveness of the support given and so on. The KB will be a web application. The interfaces previously developed are gui workstation apps, so I am not sure at this stage of the best strategy for making it all work together. Once the KB is up and running would be the best time to choose an approach.

The other items from Priorities 2006, as well as the backup issue, are under consideration. At the moment I am making backups of the database on an ad hoc basis. Ultimately management of backups together with user management should be carried out by the staff group through a web app or other interface.

An issue that was bought up some time ago was the question of how to deal with the situation of clients receiving new hosts. The old ones being returned to stock perhaps. I would like it noted that using the facility of editing existing entries via Rhadam discussed above should not be employed for this purpose. I have a way of handling this through the Database Administrators account quite easily so if any adjustments of this type are needed see me. I can remove an existing host from an application and return the system to the state where the customers application can be re-processed with a different host.

Owen Courtis ( ocourtis@dodo.com.au )

comments:

[image reference is broken]

More Comments, Observations and Suggestions --kylie, Mon, 20 Feb 2006 17:18:28 +1100 reply
Wondering if we could change the qanda label to just QA by, as it is not really Quality and Assurance, it is Quality Assurance. I also had a data entry person ask what's this qanda thing mean? :)

Next one (if not too tricky) is can we remove the Could Train check box all together? We don't use this any more and it seems to confuse people entering data. We could even lose the old data for this if that was a possibility. Not once have we asked anyone to help out. I guess it was just being hopeful.

The other issue I have on my mind is the referee section...and being able to add phone numbers. I'm not sure how important this is in the scheme of things, we can discuss it with Jan/Tony.

The other thing is adding in email addresses. We started collecting email addresses for applicants (where avail). I guess this could also be an option for referrers.

Tony also found an issue to do with spaces used at the beginning of names. If someone enters a space before starting a name when inputting data, a wild card kinda search won't pick them up.