mainstmission / food-pantry-manager Goto Github PK

So, everything in here is about people. We have neighbors, volunteers, users, donors and it's quite easy for the same person to be more than one of these. These aren't classes, they're roles.

My proposal is the create a "Person" class which only has a first/last name and then a bunch of foreign keys. That way, a person isn't repeated throughout the database.

class Person < ActiveRecord::Base
  attr_accessible :first_name, :last_name

  has_many :addresses
  # I'd just alias #is_a to #has_one to make it read better.
  is_a :volunteer
  is_a :neighbor
  is_a :donor
  is_a :user

  def has_an_address?
    addresses.count > 0
  end

  def is_a_volunteer?
    volunteer.blank?
  end

  # etc...
end

class Volunteer < ActiveRecord::Base
  belongs_to :person
end

# ...

Sure, we could put it all onto one giant Person class. But nils are the greatest evil ever unleashed on the world. And SRP tells us each class should do one thing and do it right.

Thoughts? Seeing as this will be a lot of work, if we decide this is appropriate, I will take the first stab at it.

Every person in the system will have at least one role they will be a neighbor, user, volunteer or whatever.

Some may be in households such as a husband and a wife or children, uncle brothers whatever. The Pantry has rules that a household can only get food a certain number of times a week or month.

Households would would be a has many through link with two person id field to link people together and a relationship field that specifies the relationship - spouse, child whatever.

When A person open the Neighbor view they will see the information as to that particular neighbor and the other people that are in the household

Right now the customer, volunteer, and user forms are the standard generated forms. We need to spend some time and lay out the forms and the show templates to not suck.

This allows for entry of a new neighbor -

A User should be able to enter a new Household Name
A User should be able to enter the information for the Neighbor that represents the household
A User should be able to enter Name, age, SS# for members of the Household

See Tom Hardings Mockups for an example
https://github.com/MainStMission/food-pantry-manager/wiki/Profile-View

The intake desk home page is a page that will allow the volunteer sitting is the desk to retrieve and add client information easily. Options not relevant to the task of client management will be hidden.

Initial table could be as simple as name, email and add migrations later or
first name
last name
email
phone
street
city
zip
status [active,inactive,donor,worker]
photo

This could b e self referential in that we could put them in the neighbor data base but we really just need; name, age and sex

they want biweekly reports broken down by age group, number of family members etc.

Track Donors and Donations. Print receipts for donors. Track donations' weight. Reports for donations by month.

Volunteers passes all specs but the form looks to be standard haml rather than simple_form

it looks like their might be some old instructions from before when Foreman was used. Also update the contributing guidelines if needed.

The existing users, donors, neighbors, volunteers, will become roles I assume that the authentication will remain in the role so I assume we wil have to make sure that a person is not visible except through his role

Instead of a migration this will be a "nuke" New model and migration - same information except for what was extracted to the person class

Somehow place a warning on the site when running at heroku that it's a test site and to not store anything like an actuall SSN.

edit route works but not show - on link_to for the name

Allow the admin to attach pictures to a volunteer's profile. This would be pretty awesome if it could be handled entirely from the rails app using a webcam. Chrome has exposed this using the "getUserMedia" javascript function.

Some resources:
Chrome 21 features
Building an HTML5 photobooth app

Feature: We want to track the hours that volunteers are at the mission.

As a volunteer I want to sign in and sign out when I enter and leave the mission. See the mockup below.

Scenario: Sign in at the mission
Given I am a volunteer
When I sign in
Then my time should be tracked

Scenario: Sign out at the mission
Given I am a volunteer
When I sign out
Then my time should stop being tracked

Generate a Procfile (use Foreman) to easily run the app on a local server and be able to run on heroku.

the cukes are badly written (this is entirely my fault 👎 ) I want to see them written. If anyone has read the cucumber book you know what I want to see. Eventually I'll get around to this if no one else does.

Since we will be deploying on Heroku, we will need to use environment variables to set the secret token and other application configuration options.

https://devcenter.heroku.com/articles/config-vars

We should be able to export the data within food pantry manager.

use authorization to limit Users/Volunteers/Donors/Donations to signed in users. Allow anyone to access the volunteer signin page.

Timecard should allow a user to have more than one active timecard. When a users signs in, the system should check if they're already signed in and either prompt the user to set a sign_out_time for the old card, or automatically set the sign_out_time to the current time.

@tbrooke How do you want to handle this?

Add notes to customers. Let's start this with a just a single text field.

Once we have the sign in/out feature complete, we will need to be able to view and print a report of everyone that is signed in. This report should have the pictures of volunteers. This is so an admin can quickly see how many people are currently signed in and at the mission.

Add the Project History found here.

We could add it directly to the README or create a HISTORY document and reference it in the README.

Create a basic class for a person that can be used in different roles through out the system

Last_name
first_name
middle_name
title
address
city
state
zip
phone
email
age
encrypted_ssn

So they are a plain string in the database right now, probably not best practice. Salting and encrypting sounds like a good idea, but I've never dealt with SSNs before.

We will need to control access to certain parts of the app, like volunteer management and user management. So we need an authentication/authorization setup. I imagine devise and cancan would suffice.

In regard to this issue we have some controversy at the Mission as to how we identify our customers we have discussed clients, friends etc any ideas would be apreciated

Like it says. Create a food prep list for the customer. Create a printable list for the fillers. Creation of the food prep list needs to be fast.

Right now the inventory is informal - the food list would be nonspecific user modifiable list of foods so we could do reports such as 20 cans of soup given out.

Obviously we need sign in/out working too.

Ability to print and email a volunteer hour statement to schools, businesses and governments for a specified period of time. We might want to tie this contact into a volunteers profile so that we can mass email the statements.

I want to setup travis to force a deployment to heroku if travis is still passing. I'll be following this guide http://metabates.com/2012/10/23/deploying-to-heroku-from-travisci/

Any objections?

See the TODO comment.

setup heroku instance to easily demo the app to the Mission.

At least on heroku when signing up a new user:

ActiveModel::ForbiddenAttributes (ActiveModel::ForbiddenAttributes):
2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/strong_parameters-0.1.5/lib/active_model/forbidden_attributes_protection.rb:10:in sanitize_for_mass_assignment' 2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/attribute_assignment.rb:75:inassign_attributes'
2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/base.rb:498:in initialize' 2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/models/registerable.rb:20:innew'
2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/models/registerable.rb:20:in new_with_session' 2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/app/controllers/devise/registrations_controller.rb:13:increate'
2012-11-08T01:39:10+00:00 app[web.1]: vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/app/controllers/devise/registrations_controller.rb:81:in `build_resource'

with the redesign almost every view is going to have nested attributes for the person that is in the role that the view relates to. I looked ad cocoon and awesome_nested_fields

But since we are doing this everywhere can't we create either a presenter, helper, decorator -help me here so that in our forms we have = f.input.person to pull in the person fields

Customer Signups (Robin has the information that must be saved)
Notes for customers (family needs, status updates)
Customer food list prep - Input food needs and print list for order fillers

Informal inventory - the food list would be nonspecific user modifiable list of foods so we could do reports such as 20 cans of soup given out

2nd Harvest stats- they want biweekly reports broken down by age group, number of family members etc.

The scales have a serial port. Here is my proposal assuming the server and the scale are on the same network.

Use a serial to ethernet convertor like this Device Server to attach the scale to the network.

The frontend uses ajax to send a request to the backend. The backend server will then send a request to the device server and receive the current weight. It will then send the data back to the frontend.

The backend will manage scale setup. Things like IP Address of the device server, the format the request will need to be made for the device server. Names of scales if there are more than one etc. The frontend will provide buttons to get the weight from each scale.

This will need some pretty solid work on testing and integration tests. Good logging for troubleshooting etc. What happens when we need a different type of device server since that model is no longer made? Some of this is YAGNI.

None of this work is necessary since weight can be typed. We need to discuss whether this work is worth it.

DICUSS!!!!!!

To promote contributions to the project, we can take advantage of the new CONTRIBUTING documentation that Github supports. I'd suggest move the contribution information into CONTRIBUTING.md and then pointing people to that documentation in the README.

The profile view will be the first view that a volunteer enters into when they search for a neighbor. The profile view is a page that displays all information available on a particular family. From the profile view a volunteer may also click links to edit information or initiate an interactions such as notes and visits.

Easy printing of receipts for donors. We need a quick way of printing receipts for today's donations and printing receipts that cover a range of donations (probably defined by a date range). Prawn is a good library for generating PDFs.

Get rid of the old branches that have been merged in.

To meet the April deadline. I'd like to see a milestone created and issues assigned to it. It would be nice if the milestone included all necessary features.