New Visit Display

Since the last demo, a few more features have been added - most notably, the volunteer login, the way visits are handled (displayed, edited, etc.), and the textbox with helpful prompts for food pantry volunteers.

Here is the volunteer login screen:

There is no password required at this point; all we are doing is getting the volunteer's id, so it can be recorded in visits, or the volunteer's information can be edited and viewed.

Here is the screen for viewing a volunteer's information:

When a volunteer is deactivated, they will not show up in the selection-menu on the login screen; however, an option in the "Actions" menu in the left-hand corner, will allow a user to view all volunteers, whether active or not.

When a volunteer is logged in, their id is recorded, and the next screen opens up. Here is an example client being viewed in the next screen:

You can see the textbox of helpful instructions on the left-side of the screen. These instructions are specific to the Provision Food Pantry that this database has been built for. 

Under visit information, there are many more options available. Selecting the new visit button, the visit information changes to the following:

 Note that the name of the volunteer logged in is automatically filled. The date is pre-populated to today, but can be changed if need arises. Longer notes are now possible. When the note is saved, the screen displays the following:

Selecting a visit from the listbox on the left will let you view the visit notes, the visitor that came, the volunteer that served them, and will also enable editing or deleting the visit.

Our program has finally achieved what can tentatively be referred to as full basic functionality.

Most recently, we have eliminated all global variables and replaced them with a system of classes, creating more consistent and easier-to-edit code.

We can edit, add, delete, and view clients easily as well as adding visits. Two members of the food pantry have tested it, one who is a computer scientist and one who is technologically inexperienced. Both found the program comfortable to use and helpful.

Though looking to expand possible features and functionality, there is a good working version as of right now. We have a short video showing a demo. :)

Update on Project Progress

At the beginning of this month, we announced that we were shifting our focus to the web interface. Unfortunately, there have been a lot more issues with the TkInter user interface than we expected, and it is still not entirely functioning. Since this Tk interface will be the one actually used by the food pantry, and since there are only 2-3 weeks remaining in RCOS, we will be focusing entirely on the TkInter UI for the remainder of the summer session. 

Not only will this allow us to turn out a working database, but also the quality of the interface will be better than if we tried to finish two interfaces at once. Since this database will probably be used by the food pantry for several years, this quality is especially vital.

Any work already done towards the web interface has been posted under a module called experiServe.py; this should create a very basic interface using html and the built-in Python server, and will accept input and print it to the screen (it has not been connected to the database at all yet).

 

Big changes are in progress to the functionality of the blog. Everything is ALMOST working and displaying information correctly. Hopefully within the next few days everything will all be cleaned up. Also, the new client UI (which is basically just a dynamic rearrangement) of the information display is pretty much up and kicking.

Here's the main Gui as of now:

 And here is the new client arrangement. In the bottom section, there is an entry box to specify the number of family members and an appropriate number of boxes pops up to be filled out.

Research & Future of This Project

Right now, we are in the process of finishing up the TkInter UI, and researching Python modules for phase two of the project. Please note that with the completion of the TkInter UI, we will have a working database that the food pantry can use. Phase two of the project is an attempt to set the database on track for future versions that can include a website, android app, and so on.

To create version 2 of the database, we are looking at how to configure Postgres, and will probably be using the psycopg2 Python module. For the web server, the wsgiref module will be used for testing purposes; however, a later version of the database will probably use a more secure web server, such as Apache (we may or may not reach this step, depending on the complexity of it). Finally, the web UI will be implemented using HTML, and, ideally, Javascript.

Sqlalchemy and TkInter were new experiences for us, and we are moving into even more unfamiliar ground, having little to no experience with HTML, Javascript, Postgres, or web servers. As a result, our progress may be a little slower than we would like, but we're looking forward to the challenge, and we welcome any helpful comments or suggestions you might have.

Revised Client Information Gui

This is the revised page with client select/search on the lefthand, and client information and editing on the right. I have tried to make as much functionality present on one main screen, but without becoming too cluttered.

 This should help move along the processing of clients when there is a rush.

Within a few days, the revised database functions should be hooked into this new set-up and there will be a fully functional model!

Tests & Trouble

The return for select_client has been simplified even more, so that it now returns a dictionary of objects. A file that can be used to test the update_all, new_household, and select_client functions has been added to the repository.

The hang-up at the moment, for the back-end part of the database, is generating CSV files using sqlalchemy. Figuring out how to select the right data from the tables, and get it written to a CSV file has proved tricky so far, but this will hopefully be resolved quickly.

In addition to researching the csv.writer for Python, we are starting research on PostgreSQL, and the built-in Python web server.

Interface Updates

Along with the updated database functions I updated the version of the user interface, which has been made to actively display and interact with database information. This version was compatible with the function files created on June 23rd. Those functions have since been updated (as of June 26th) and I am reworking the client info menu to be compatible with the new versions.

Unfortunately, I didn't get a screen shot before updating the old function files, but hopefully I can have a new version of the client info menu up and running soon.

It also should be noted that I have switched around the flow of the interface following a visit to the food pantry and seeing the flow of data entry. The Client Info page has now been mated with the main menu and is the primary page. Also, it is now Light Sea Green, though color choice is definitely subject to change.

Delete functions

The delete functions were added to the repository, in files called cdbfunctionsV2.py, and cdbifuncV2.py (these files were added with a different name to help keep track of compatibility with the interface.

The files containing the queries are nearing their final version; the only additions needed are functions that will generate csv files for reports. Once these are completed, the back-end for the sqlite-version of the database will be finished. The next step will be making some modifications so the same queries are compatible with Postgres.

Finally simplified function calls

First of all, the new_client function has been renamed to new_household, since we are typically adding more than one client at a time.

Secondly, because we are adding multiple clients at once, it is necessary to keep relevant data together (e.g. one client may have a phone number while another may not, and we needed to associate these phone numbers with the correct first name, last name, and dob). We attempted to use lists and tuples to solve this problem, but the function calls become virtually indecipherable, and there was a lot of potential for index-out-of-bound and other errors. However, all of these issues have been resolved by creating a number of objects to hold the data that will be sent to the functions. This not only resolves a lot of errors, but also makes cleaner, easier to understand functions.

On the interface end of things, there's been a bunch of work done on creating and then improving the window to view client information. This is the first version which is a semi-functional skeleton:

It was connected to some of the old database functions.

It has since been expanded and necessary features have been added to it including visit information and connections to the new set of database functions.

Some of the information (like the notes, visit dates, volunteers) are hard-coded strings just to show an example but will soon be replaced with functions that pull the information directly from the database.

Function redefinitions

The list_people function was changed to return the street_address of each person, in addition to the first name, last name, and unique id. Another small function, new_volunteer, was added.

The arguments for the new_client function were becoming difficult to manage. In addition, after writing a good portion of the update_client function, it became clear that there needed to be more "connectedness" between the bits of information that belonged to a single client. Instead of receiving individual lists of first names, last names, etc., the function now takes a list of tuples, where each tuple contains a first name, a last name, etc. This will be necessary for the update_client function, where multiple clients may be updated at once, and we need to associate the new data with the right id. In an effort to conserve as much consistency across the functions as possible, this was applied to the new_client function as well.

More functions & session error corrected

The cdbfunctions.py module was updated to include another function for inserting new visits, and two functions for updating a household and an individual's records.

Since this module contains "helper" functions for the another module, it was using the current session, but had no way of accessing the current session, so this was fixed by adding the session as another argument to each insert/update function.

User Interface Additions

Initial models of the user interfaces for the main menu, login menu, and addition of a client have been created using tkinter (the python module). They are still in a skeletal and somewhat janky phase right now, but can be used to test out connecting user actions to simple database queries.

Module split & additional functions

The python module containing all functions has been split into two modules. There is now a module for functions that will be called directly by the user interface, and a module of "helper" functions. This will hopefully make the interface design much easier. In addition, the following functions were added to the repository: reset, select_client, list_people, and get_age_breakdown.

Added functions

Fully tested, basic functions added to repository. These functions deal with the case of adding a new client and household to the database. The functions are organized to be as clear as possible, so they can easily be called by the interface.

Table Definitions

The tables of the database have been defined, using the Python sqlite database, and the sqlalchemy module. The functions (queries) and TkInter interface are still in progress. Once completed, this will conclude stage one of the project, building a prototype.