rubyforgood / human-essentials

Human Essentials is an inventory management system for diaper, incontinence, and period-supply banks. It supports them in distributing to partners, tracking inventory, and reporting stats and analytics.

Human Essentials

Mission 💖

Human Essentials is an inventory management system built to address the needs of Diaper Banks as directly and explicitly as possible and adapted to meet the needs of other Essentials Banks. Essentials Banks maintain inventory, receive donations and other human essentials supplies (e.g. diapers, period supplies), and issue distributions to community partner organizations. Like any non-profit, they also need to perform reports on this data and have day-to-day operational information they need. This application aims to serve those needs and facilitate the general operations of the Diaper Banks (e.g., using barcode readers, scale weighing, inventory audits).

Impact 🌟

Human Essentials has over 200 registered banks across the United States at no cost to them. It is currently helping over 3 million children receive diapers and over 400k period supply recipients receive period supplies. Our team is in partnership with the National Diaper Bank Network (NDBN) and can be found in their annual conference that brings numerous of non-profit organizations that distribute essential products to people.

We are proud of our achievements up to date but there is much more to do! This is where you come in...

Ruby for Good

Human Essentials is one of many projects initiated and run by Ruby for Good. You can find out more about Ruby for Good at https://rubyforgood.org

Digital Public Good 🎉

The Digital Public Goods Alliance recognizes Human Essentials as a digital public good (DPG). This project supports the following Sustainable Development Goals:

• SDG 1 - End poverty in all its forms everywhere
• SDG 3 - Ensure healthy lives and promote well-being for all at all ages
• SDG 10 - Reduce inequality within and among countries

Use as an Organization or Contribute as an Individual/Team to this Project:

• NGO Adoption Info - information about how to use this DPG
• Skills Based Volunteering Info - information about how to volunteer

Welcome Contributors! 👋

Thanks for checking us out! If you're new here, here are some things you should know:

• Issues tagged "Help Wanted" are self-contained and great for new contributors
• Pull Requests are reviewed within a week or so
• Ensure your build passes (rubocop -a is often necessary) and addresses the issue requirements
• This project relies entirely on volunteers, so please be patient with communication

Join us on slack 💬

You can sign up here and find us in #human-essentials. Many helpful members are available to answer your questions. Just ask, and someone will be there to help you!

Getting Started 🛠️

1. Install Ruby
   • Install the version specified in .ruby-version.
   • Visit the Install Ruby on Rails guide by GoRails for Ubuntu, Windows, and macOSX setup. ⚠️ Follow only the Installing Ruby step, as our project setup differs ⚠️ It is highly recommended you use a ruby version manager such as rbenv, asdf, or rvm.
   • Verify that your Ruby installation works by running ruby -v.
2. Install Postgres
   • Follow one of these guides: MacOSX, Ubuntu.
     • Do you develop on Windows? We'd love to hear (and for you to submit a PR explaining) how you do it. 🙏🏻
   • Create a database.yml file on config/ directory with your database configurations. You can also copy the existing files called database.yml.example and .env.example and change the credentials.
3. Run bin/setup
4. Run bin/start and visit http://localhost:3000/ to see the human essentials page.
5. Login as a sample user with these default credentials (which also work for staging):

Super Users 🦸🏽‍♀️

  username: [email protected]
  password: password!

Bank Users 🏦

  Organization Admin
     Email: [email protected]
  Password: password!

  User
  Email: [email protected]
  Password: password!

Partner Users 👥

  Verified Partner
  Email: [email protected]
  Password: password!

  Invited Partner
  Email: [email protected]
  Password: password!

  Unverified Partner
  Email: [email protected]
  Password: password!

  Recertification Required Partner
  Email: [email protected]
  Password: password!

Troubleshooting 👷🏼‍♀️

Please let us know by opening up an issue! We have many new contributors come through and it is likely what you experienced will happen to them as well.

• "My RBENV installation didn't work!" - The rbenv repository provides a rbenv-doctor script to verify the installation and check if a ruby version is installed

Contributing Guidelines 🤝

Please feel free to contribute! Priority will be given to pull requests that address outstanding issues and have appropriate test coverage. Focus on issues tagged with the next milestone for higher priority.

To contribute:

• Identify an unassigned issue
• Assign the issue to yourself to avoid duplicated efforts (or request assignment by adding a comment)
• Fork the repo if you're not a contributor yet
• Create a new branch for the issue using the format XXX-brief-description-of-feature, where XXX is the issue number
• If you create a new model run bundle exec annotate from the root of the app
• Create tests to validate that your work fixes the Issue (if you need help with this, please reach out!)
• Commit locally using descriptive messages that indicate the affected parts of the app
• Ensure all tests pass successfully; if any fail, fix the issues causing the failures
• Make a final commit if tests needed fixing
• Push up the branch
• Create a pull request and indicate the addressed issue in the title

Squashing Commits

Consider the balance of "polluting the git log with commit messages" vs. "providing useful detail about the history of changes in the git log". If you have several smaller commits that serve a one purpose, you are encouraged to squash them into a single commit. There's no hard and fast rule here about this (for now), just use your best judgement. Please don't squash other people's commits. Everyone who contributes here deserves credit for their work! :)

Pull Request Merging

At this point, someone will work with you on doing a code review. If the automated tests gives 👍 to the PR merging, we can then do any additional (staging) testing as needed. Finally if all looks good the core team will merge your code in; if your feature branch was in this main repository, the branch will be deleted after the PR is merged. Deploys are currently done about once a week!

In-flight Pull Requests

Sometimes we want to get a PR up there and going so that other people can review it or provide feedback, but maybe it's incomplete. This is OK, but if you do it, please tag your PR with in-progress label so that we know not to review / merge it.

Becoming a Repo Contributor

Users that are frequent contributors and are involved in discussion (join the slack channel! :)) may be given direct Contributor access to the Repo so they can submit Pull Requests directly instead of Forking first.

Stay Scoped

Try to keep your PRs limited to one particular issue, and don't make changes that are out of scope for that issue. If you notice something that needs attention but is out of scope, please create a new issue.

Debugging

If starting server directly, via rail s or rail console, or built-in debugger in RubyMine, then you can use binding.pry to debug. Drop the pry where you want the execution to pause.

If starting via Procfile with bin/start, then drop a binding.remote_pry into the line where you want execution to pause at. Then run pry-remote in the terminal to connect to it. https://github.com/Mon-Ouie/pry-remote

Testing 🧪

Writing Tests/Specs

• Run all the tests with bundle exec rspec
• Run a single test with bundle exec rspec {path_to_test_name}_spec.rb

Make sure all tests run clean & green before submitting a Pull Request. If you are inexperienced in writing tests or get stuck on one, please reach out for help :). You probably don't need to write new tests when simple re-stylings are done (ie. the page may look slightly different but the Test suite is unaffected by those changes).

Tip: If you need to skip a failing test, place pending("Reason you are skipping the test") into the it block rather than skipping with xit. This will allow rspec to deliver the error message without causing the test suite to fail.

  it "works!" do
    pending("Need to implement this")
    expect(my_code).to be_valid
  end

Writing Browser/System/Feature Specs

If you need to see a browser/system spec run in the browser, you can use the following env variable:

NOT_HEADLESS=true bundle exec rspec

We've added magic_test which makes creating browser specs much easier. It allows you to record actions on the browser running the specs and easily paste them into the spec. You can do this by adding magic_test within your system spec:

 it "does some browser stuff" do
   magic_test
 end

and run the spec using this command: MAGIC_TEST=1 NOT_HEADLESS=true bundle exec rspec <path_to_spec>

See videos of it in action here

Deployment Process 🚀

The human-essentials & partner application should ideally be deployed on a weekly or bi-weekly schedule depending on the merged updates in the main branch. This is the process we take to deploy updates from our main branch to our servers.

Requirements

• SSH access to our servers (usually granted to core maintainers)
• Login credentials to our Mailchimp account

Tag & Release

1. Push a tag with the appropriate semantic versioning. Refer to the releases for the correct versioning. For example, if the last release was 2.1.0 and you're making a hotfix, use 2.1.1

   git tag x.y.z
   git push --tags

2. Publish a release associated to that tag pushed up in the previous step here. Include details about the release's updates (we use this to notify our stakeholders on updates via email).

Running delayed jobs

Run delayed jobs locally with the rake jobs:work command. This is necessary to view any emails in your browser. Alternatively, you can run a specific delayed job by opening a Rails console and doing something like:

Delayed::Job.last.invoke_job

You can replace the last query with any other query (e.g. Delayed::Job.find(123)).

Additional Notes

• Only commit the schema.rb only if you have committed anything that would change the DB schema (i.e. a migration).

Acknowledgements

Thanks to Rachel (from PDX Diaperbank) for all of her insight, support, and assistance with this application, and Sarah ( http://www.sarahkasiske.com/ ) for her wonderful design and CSS work at Ruby For Good '17!

License

✨ Contributors ✨

Thanks goes to these wonderful people (emoji key):

Edwin Mak 💻 📆 🚇 🤔 💬 🛡️	Sean Marcia 💻 💼 💵 🔍 📋	Aaron H 📆 💻	Dmitry 💻	Adam Bachman 💻	JC Avena 💻	mdworken 💻 📆
Marius Pop 💻	Elayne 💻	Amy Detwiler 💻	Gia 💻	Amina Adewusi 💻	albertchae 💻 🤔	Keith Walters 💻
Chase Southard 💻	Brock Wilcox 💻	danquill 💻	Keith Bennett 💻	Benjamin Reynolds 💻	jtu0 💻	Juarez Lustosa 💻
Julien A. 💻	Emerson Manabu Araki 💻	Ben Klang 💻	karolina 💻	Josh Cano 💻	Julian Macmang 💻	Philip DeFraties 💻
GabrielRMuller 💻	Lucas Hiago 💻	Lanya Butler 💻	Eduardo Moreira 💻	Alicia Barrett 💻	Bob Forcha 💻	William Murphy 💻
Kate Donaldson 💻	Matthew Russell Dodds 💻	Allison McMillan 💻	Ashley Jean 💻	Eduardo Alencar 💻	Thomas Hart 💻	Bart Agapinan 💻
Monique 💻	Valerie Woolard 💻	zak-kay 💻	Jason LaHatte 💻	Dave Tapley 💻	Meghan 💻	Andy Thackray 💻
Felipe Lovato Flores 💻	Marcel Kooi 💻	Lee Sharma 💻	Scott Steele 💻 🤔	Sam Weerasinghe 💻	Gerald Abrencillo 💻	Rodolfo Santos 💻
Gabriel Baldão 💻	Melanie White 💻	Melissa Miller 💻	Marc Heiligers 💻	Joe Hunt 💻	Meg Gutshall 💻	Andrew H Schwartz 💻
Joseph Glass 💻	Reese Williams 💻	Santiago Perez 💻	Sirius Dely 💻	Heather Herrington 💻	Moacir Guedes 💻	CraigJZ 💻
Semih Arslanoğlu 💻	Mauricio de Lima 💻	David Curtis 💻	Natalia Galán 💻	Anderson Fernandes 💻	Gabriel Belgamo 💻	Jorge David C.T Junior 💻
Seth Lieberman 💻	Jorge Oliveira Santos 💻	Drinks 💻	Bruno Castro 💻	Carlos Palhares 💻	Clifton McIntosh 💻	Daniel Beigelman 💻
Meg Viar 💻	Svetlana Vileshina 💻	Ben Reed 💻	Emily Giurleo 💻	Alem Getu 💻	Dejan Bjeloglav 💻	Cassiano Blonski Sampaio 💻
Greg 💻	finn 💻	Jayson Mandani 💻	Stanley Liu 💻	Curtis Bartell 💻	Libby Rodriguez 💻	joshuacgraves 💬 📆
Himanshu 💻	Mohamed Hegab 💻	Alejandro AR 💻	hatsu 💻	Matt Glover 💻	js-sapphire 💻	lasitha 💻
Patrick McClernan 💻	Marc Bellingrath 💻	Daniel Orner 💻	Bob Mazanec 💻	Mark Yen 💻	Rachael Wright-Munn 💻	Ítalo Matos 💻
Alvaro Sanchez Diaz 💻	mbrundige 💻	Robert Greene 💻

This project follows the all-contributors specification. Contributions of any kind welcome!

human-essentials's Issues

User can provide a quantity of boxes when scanning a barcode

When a user scans a barcode, and that barcode exists (or they have finished providing the details for that barcode item), they should be able to provide a quantity of instances for that barcode.

From the original issue:

As you know, I currently scan each package/box's barcode which I've assigned a diaper quantity to. But, let's say I happen to have 20 packs/boxes of the same product in the mix of incoming donations-- is it possible to add a function in which I can input the quantity of the packs/boxes I'd like to put into inventory? With the current setup, those items would need to be scanned 20 times (which take a lot more time and leaves room for scanner/human error).

When a user scans a barcode, if it doesn't exist in the system, it prompts the user to create a new entry

This functionality existed in the previous app ( https://github.com/rubyforgood/pdx_diaper, see files: https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/barcode_item.rb and https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/donation.rb ) but needs to be re-created with the new UI / workflow.

Need to handle users in different timezones

Users should be able to select their timezone so the timestamps on their data and their date range filters more accurately reflect the region they live in.

User can filter reports by multiple date presets

When browsing the reports (Dashboard aggregate reports, Donation / Ticket / Transfer reports, etc), the user should be able to constrain the view by date (probably created_at?). Rachel has suggested having some "preset" UI controls for this would be useful for her.

E.g. filter by “today”, “Yesterday”, “last week”, “last month”, “last year”, etc.

These can all use the same date-range scope (which does not yet exist, I think?) and just have pre-calculated values for those controls.

A user can transfer items from one inventory to another

There is existing functionality for this: https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/transfer.rb

This would be used when the user wants to move inventory from one storage location to a different one (but NOT when they're issuing a distribution ticket)

Lock gems at known good versions to prevent future breakage

A user's use of the app is authorized to just their own tenancy

When a user is interacting with the site, they do not see other user's data and they cannot access it by accident. Authorization enforces this privacy.

Create seed file of EAN13 codes for known products

Probably starting with something like this:
http://www.product-open-data.com/product-brand-list-4I3EU6.html

Create a seedfile (YAML?) of as many different products possible that can be loaded in as BarcodeItems, to minimize the amount of user-entry required. Unclear how many products would need to be entered, but the more seeds we have the less manual entry users have to do.

Add `Adjustment` itemizable model to manage manual inventory changes

Receipts and distributions needs to support being filed on past date

Currently the Donation and Distribution models have a created_at date which is used to denote the date the object was received or issued. But in some cases the user needs to be able to file one of these events for a past date. For example, if a diaper drive happened in a past month, the staff may not have gotten to issuing it yet. So when the record is created in the system the user needs to be able to specify the past date they want the event to occur on.

This needs to be reflected in any reports used to aggregate donations or distributions by date.

Donation::SOURCES needs a refactor

Mentioned in #89 --

/app/models/donation.rb has a SOURCES array of strings that has the different options that can be used for the source field. Up til now this was mostly limited to the donations views.

With the changes in #89 though, the string literals are being referenced elsewhere. Changing the wording of the strings in SOURCES will thus have "OMGWTFBBQ" breakage. It's unlikely the types will change so this can probably be fixed by making SOURCES into a hash and referencing the hash-keys instead of the strings directly. (ie. Donation::SOURCES[:dropoff_location] instead of "Donation Pickup Location")

Static Content for the site needs to be created (Landing pages)

Before we can launch the site, we need to have some static content created.

We should loop in @pdxdiaperbank with some suggestions about what sorts of information would be useful to include for potential tenants.

We'll also need to enumerate what static pages need to be created.

A user can scan a barcode item to quickly add an item to a donation, distribution, etc.

When a user has an in-progress donation, they can add items to the donation by scanning them with a barcode. (Assume that the items have already been added to the system)

This function existed in the previous app ( https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/donation.rb ) but needs to be re-created with the new UI/workflow

A user can add items to a donation in progress

When a user has an existing donation already in progress, they can add items to it (a pending test exists for this). This feature existed in the previous app ( https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/donation.rb )

Enforce Organization Logo Dimensions

Currently, we don't enforce any dimensions on the uploaded logos. Consequently, if a large strangely shaped logo is uploaded it will be outside the desired area on the pdf printing. The default image is 763 x 188 pixels and we should enforce something like that to ensure consistency.

This is a pretty easy fix in paperclip if someone wants to tackle it.

Here is an example of what I'm talking about.

Add title to pages

Add

<% content_for(:title, "Title Goes Here") %>

to the top of every top-level page (not partials). See dashboard#show for an example.

Adding additional fields for donations of certain types

Rachel would love it if the new donations form could include additional source information above and beyond simply the source type, i.e. if the source is a diaper drive, having an additional field to enter the specific diaper drive, or if the source is a purchase being able to enter where the purchase was made/who made it/the purchase date, etc.

This ticket will likely require some additional coordination with Rachel to get a solid grasp of all use cases.

An Administrator can create or manage tenants

A superuser / administrator can perform CRUD tasks on tenants (spinning up new instances, managing existing ones, etc)

Populate the diaper database from a seeds script

We need a db/seeds.rb script to populate the diaper database with useful records to help with development and testing

Rename `Inventory` to `StorageLocation`

The Inventory model actually represents where items are being stored, because it has a location and relates to the what (inventory items).

The actions that we would do to an inventory are really actions that would take place between facilities, or locations, such as a transfer. This enables us to treat inventory items as the inventory itself. Now a storage location can have multiple items in inventory.

Fix Navbar Responsive

When the hamburger is clicked in mobile view the navbar links are displaying horizontally.
They should display in Vertical Menu list format.

A user can create a ticket to distribute inventory to a community partner

This functionality existed in the previous app (https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/ticket.rb) so the model methods should be reusable.

There was some discussion about the workflow being different from the donation workflow, so some discussion should be had about how to best do this (cf. #22 and #23 and the discussion from the issue in the previous project: rubyforgood/pdx_diaper#54 )

All drop-down lists should be alphabetized

From Rachel:

Alphabetize all drop-down/select lists. Difficult to quickly find items in inventory drop-down lists.

This could ostensibly be addressed with a default_scope { order(:name) }, though test it thoroughly (w View specs, not just model scope specs) to be sure.

New Donation create without selecting item breaks item dropdown

To generate this bug go to new_donations_path click Create Donation without setting quantity value. It will throw errors and the item dropdown will change to a number select field. The path also redirects the url to donations_path without refreshing.

A user can remove an item from an in-progress donation

When a user is working with a donation that's in-progress, they can remove an item that is in the donation

(this feature existed in the previous app: https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/donation.rb )

Users can see a dashboard with reports of aggregate data

This functionality exists on the 2016 app ( https://github.com/rubyforgood/pdx_diaper -- /app/admin/dashboard.rb) and needs to be re-created on the new app.

This will be related to issues #13, #8, and #11

User can track loose diapers for intake using a digital scale

A user should be able to add loose inventory via weighing the product on a scale. Here are the notes from the previous year:

1. You click on the scale tab
2. You click on the diaper type (ie- disposable inserts), size (NB, 1, 2, 3, etc) (*)
3. You dump the diapers into a container on the scale
4. It displays how many diapers are in the container (ie - 82 diapers)
5. You then click "Add to Inventory" and it adds them to the inventory (ie- 82 disposable inserts to PDX Diaper Bank (Office))

[* Rachel also mentioned "count", though I'm not clear on what that's referring to]

Relevant links (from @seanmarcia )

• https://developer.chrome.com/apps/hid
• https://keetrax.com/blog/2015/01/interacting-usb-hid-devices-web-apps/

The app is capable of supporting multiple tenants

This app is intended to become a SaaS, and so it needs the ability to support all the core app functionality separately from other users.

When adding a donation with "Diaper Drive" as the source, it prompts for a Community Partner

From Rachel

Add “Community Partners”to address book. So we can make note of the businesses that are hosting the
diaper drives on the receipts we’re creating

This could possibly be integrated with #4 in creating a Source model. Inquire with Rachel further about how the "source" field is similar or different from a "community partner".

The model should be similar to "DropoffLocation" in terms of data, and maybe both of them could just be the same model with polymorphism?

Donation#new should allow "Misc Donation" to accept user input

The "source" field is currently a single drop-down list, populated from an array of Strings, found in /app/models/donation.rb

There is a "Misc Donation" option to choose from, but it does not currently allow for any override or comment from the user.

Notes from 2016:

This would need to probably refactor sources to be a separate model (so that "other" is an option) or it could add an additional "misc_comment" column to the donations table. Would probably want to override the accessor/mutator for the source field to accommodate the "Misc Donation" data? (like, when it's reading that field, if it says "Misc Donation" as the source, it concatenates the "misc_comment" field to the end, and when it's assigned, it splits that apart.)

Rachel would essentially like the ability to provide a comment for any given Donation (ie. "Diaper drive" but then specify "Portland Safeway" or similar)

A tenant can put a custom logo in the masthead of the app

From Rachel:

Create a way for individual users to add logo to header of website (so it appears on every webpage). People in nonprofit take such pride in their organization. Having the logo there enriches this, and makes the tedious work of data entry more fun!

This will require the ability to upload images (and store them); Paperclip or similar should work?

A user can change the quantity of an item in an in-progress donation

When working with an in-progress donation, the user can change the quantity of an item

User can scan a barcode to add items while creating a distribution ticket

When a user is working on a distribution Ticket, they should be able to add Items to the Ticket by scanning a barcode instead of choosing from a drop-down list.

The dasbhoard should have "current inventory summary" snapshot data

From Rachel:

Need to easily see inventory on hand. Inventory summary on dash = current items on hand??

The Dashboard still needs to be re-created, so this could be addressed implicitly in that task.

Validation for URL on Organization needs better error messages

If the user doesn't provide http:// at the beginning of the url for their organization the validation fails but doesn't explain why.

We should probably make the error message more clear, and I would also recommend removing the requirement to having http:// added by the user. Not everyone is going to thing to do this. Most people thing of websites as just the domain they know.

User can edit/remove inventory count from any category

From Rachel:

Must have a way to remove/adjust inventory count from any category! Sometime items get entered
incorrectly, not caught until later, then needs to be removed from inventory.

The big concern, for data integrity, is that there is some kind of audit record for the change.

There are a few different ways this could be approached -- if it were possible to adjust the erroneous donation, (via Donation#Edit) then the existing audit trail is preserved, although I suspect that this will not address all possible cases (maybe they do an inventory count and notice discrepancies but don't know if it's inventory shrinkage or a typo in the intake).

Another possibility is to create an Adjustment model to track these inventory changes. The quantities are changed directly in the inventories themselves, but there is a record on file (with comment) indicating the change. This could then be included in reports so that the totals add up correctly.

ie, for Item X:
(Donation total: 110) + (Adjustment total: -10) - (Distribution total: 50) = (Inventory total: 50)

Rename holding to inventory_item

The wording of holding is confusing and should be renamed so it better reflects what it represents.

Inventory should be immediately accessible for distribution after being entered

This was raised as an issue with the previous app. It may or may not affect this new app (since ActiveAdmin has been removed), but it was raised as a need by the Org, so let's make sure that it works as expected! :)

Issue from PDXDB, as written:

For example, I recently entered a bunch of size 6’s into the
database that were purchased. Then, when I went to create a ticket for distribution, it said that there wasn’t
enough size 6’s in inventory to create my ticket. Why?

Rename containers table/model to line_items

User can export reports

from Rachel:

Downloadable graphs/statistics. All of those wonderful graphs would be an fantastic addition to presentations, meetings, and proposals— can we make is so I can create select a date range and download all of the graphs/statistics that upload to the dashboard?

A user should be able to export a report in Excel (CSV should be fine) format at a minimum, showing whatever the user is currently seeing. They can then create charts in Excel manually.

A stretch goal for this would be to make the charts themselves downloadable somehow.

Items page should show current inventory totals, broken down by storage location

When a user visits the Items#index action, they should see an inventory sum total, broken down by storage location, with rollup, for each item.

A user can reclaim (revert) a Distribution that was already finalized

If the user finalized a ticket (and inventory was reduced) the ticket can be "reclaimed", reversing the distribution.

This feature was previously implemented, for reference: https://github.com/rubyforgood/pdx_diaper/blob/master/app/admin/ticket.rb The model methods still exist, I believe.

Fill Out CRUD Functionality for Donations

Currently users can create donations, but there's no good way to read/edit/delete them. This ticket is to add that functionality.

One caveat: Need to make sure that deleting/editing a donation doesn't necessarily delete the records, but rather adjusts the inventory quantities.

Javascript undefined is not an object error on most pages

Looks like the JavaScript firing on every page includes a snippet from the distributions.coffee that is pulling an object from the DOM and trying to call other functions on that object. In particular, this section:

$(document).on "turbolinks:load", ->
  control = $("select#distribution_storage_location_id")
  $.ajax
    url: control.data("storage-location-inventory-path").replace(":id", control.val())

Is expecting a select#distribution_storage_location_id to exist and then calls data() on it. However that control only exists on the new or edit distributions pages. This JS should be updated to only execute on the page it applies to.

Rename tickets table to distributions

Site layout & basic navigation

The app is set up with the Foundation 6 framework and a very basic default layout. It needs to look a bit more well put-together and have a site navigation.

DB Seed data doesn't include orgs and new storage location

DiaperDriveParticipant needs CRUD for management

The DiaperDriveParticipant model was created in #89 but does not have any management features (other than via rails c-fu)

Basic CRUD features should be added (maybe not "destroy"?) similar to the other community partner models. A menu item under "Community" would be a good place to put a link for it.

Model has validations already -- pretty much just the UI and Controllers needs to be created.

A user can log into the site and is authorized for their instance

self-explanatory

Probably use Devise for authentication? Maybe with OAuth and possibly some third-party authentication means?

A user can print a finalized ticket (to PDF?)

The printed ticket should probably have a manifest of the contents, the inventory it's coming from, and the partner it's being distributed to, as well as the user that prepared it (and the date?)

I don't think this feature was completed on the previous app.

Printing to PDF may not be necessary if other means are better.