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

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

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

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

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?

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 )

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?

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.

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.

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.

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 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/

Add

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

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

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.

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.

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.

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.

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.

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.

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

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")

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.

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

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.

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)

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.

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).

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.

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

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.

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.

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 "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)

self-explanatory

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

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.

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.

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.

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 )

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.

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)

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.

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.

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.

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.

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 )