Workflow for Creating a Donation is different than Creating a ticket

[armahillo]

Currently:

• When creating a donation, you create the donation and then add stuff to it.
• When creating a ticket, you first open a ticket, add stuff to it, then create it.

Expected

• Both processes would function similarly.

TODO

I think the latter is more intuitive, though it would be important to ensure that the barcode process is still preserved in that (you can just type ina series of numbers and press "enter" to simulate a barcode read). I know the Ticket process has some extra foo with the nested containers and all that.

Thoughts, anyone?

[cattywampus]

I agree that the two workflows should behave similarly to the user and that the 2nd option might be more intuitive. Currently when a user creates a donation, they don't actually define any donated items but the button says Create Donation which might be confusing.

That being said, the current implementation does lend itself nicely to allowing users to add multiple items manually or with barcodes. Implementing a nested form type of change would also require a little JavaScript love for the Barcode form to update the line items asynchronously instead of issuing full on POST form submissions and page reloads like it does today. All in all, not insurmountable.

Another implementation detail to think about is what to do about donation state. If we switch to a nested form for donations, do we still need/want a concept for open/closed donations? Would the expectation be that when a user is building out the donation by selecting the donation attribute fields and adding multiple items, then when they click the Create Donation button it creates the donation and updates inventory?

This might be a good conversation to have the customer to weigh in on.

[armahillo]

I agree that we should consult with Rachel (customer) about this.

I hadn't considered the potential JS complication when doing the barcode wizardry -- that's a good point. Perhaps we could do a hybrid solution? In-flight Donations are still supported so they can "save and return later" but the primary workflow is closer in functionality to Ticketing?

Just spitballing here:

1. User starts new donation
2. User adds N items through normal form interface, similar to Ticketing (JS magick that adds new nestedForm blocks)
3. User can add N items through Barcode reading, but CRLF is captured and suppressed -- XHR fires and returns a partial that contains the nestedform partial, appended to the series
4. User clicks "create donation" (maybe we should rename this so that it's more contextually appropriate for the user's expectation -- like "Add these items to inventory")
5. POST#create fires

We could add a "save for later" that fires POST#create but just creates the donation without closing it or doing the intake! method.

Thoughts?

[christine-sm]

The above sound like a good plan to me. What is XHR? Is that related to the HTTPRequest?

[armahillo]

XHR = XmlHttpRequest, or "ajax", yeah. :)

[pdxdiaperbank]

@armahillo , @cattywampus , & all:
I did notice the difference in the "flow" when creating a ticket vs. a donation/receipt. Although the process is inconsistent, it is something that we can work around. But, if it is a fairly simple fix without complications, feel free. :)

[armahillo]

@pdxdiaperbank We'll see what we can do. :)

This is related to #65

[cattywampus]

@pdxdiaperbank do you prefer the workflow for how donations are entered or how tickets are entered (ignoring the barcode stuff for now)?

The difference being donations require you to create them first, add items to it, and the mark the donation as completed. Whereas when you create a ticket, you input everything in one shot, selecting each of your inputs and adding items, and then clicking the create button.

Judging by the conversation between myself and @armahillo we are leaning towards the latter, ticket flow. But let us know if you have a preference to make everything behave like the donation process.

[pdxdiaperbank]

@cattywampus Yes, the ticket flow is probably preferable. Makes a little more sense. :)

[cattywampus]

Thanks for the input.

[armahillo]

Since the other 2 MVP Issues are already assigned, I'll take this one! @cattywampus are you still good on managing the other issue? Or do you want to swap?

[armahillo]

I've got an in-progress branch that replicates the functionality of Tickets, but in Donations. Trying to noggin through the barcode trickery while keeping the Ticket workflow.

Found this: https://stackoverflow.com/questions/1954773/rails-nested-attributes-javascript-add-another

Any thoughts on this, @cattywampus ?

[armahillo]

OK I pushed up my progress so far. I'm kinda stuck on this -- The current method uses the "Rails Way" of doing has_many containers in the nested form, and it'd be nice to maintain that because it's clean and encapsulates a lot of the UI logic -- but I'm not sure how to do the barcode addition while still maintaining that -- is that even possible?

Any thoughts @cattywampus or @seanmarcia ?

[seanmarcia]

I'll have to dig deeper into the bar code functionality. I actually haven't looked yet into how the bar code part works... I've been putting it off until I can get my hands on a reader.
I'll grab the branch and look in a bit.

[armahillo]

@seanmarcia Barcode is simpler than it seems. It just inputs the string of text (numbers mainly) and fires a carriage return. You can simulate it by literally doing that manually.

[seanmarcia]

That's pretty nifty. Isn't there a library or something that converts barcode to ascii or something like that? I assumed that some sort of translation occurred somewhere that needed to be accounted for :)

Can we print "custom" barcodes and use the barcode scanner to read them? I was thinking about the issue about quantity #71 and was wondering if would could just have two fields that are scanned. One of for the quantity and one for the item. For the quantity we could ask Rachel to print out a page of various quantities that make sense to her (1,2,3,5,10,20,etc) and then keep that page handy when doing intake.

I image the process to then be that she first scans the quantity, say it is 20, then she scans the bag of diapers. This would change the workflow for single bags of diapers in that she'd now need to scan the 1 and then scan the bag.

Does that make sense? Since it fires a carriage return we'll likely need to use javascript on the quantity field to ensure it tabs to the next field and doesn't submit after the scan.

I'll be digging into your branch tonight now that the other MVP issue has been knocked out.

[armahillo]

The translation from barcode to ASCII is done by the barcode reader itself, I think.

Doing custom barcodes would certainly be a possibility but that would have to be a Mark2 feature I think.

The way the workflow happens right now (on the existing app): You can a barcode in, and it checks the DB for existing records for that item -- if it finds none, then you specify what it is and the quantity for that package, then any future instances of that item should map to that combination. The lookup is an ajax call, but it posts the form as an update after each iteration.

That's been the tricky part with the conversion in workflows -- the worfklow used for Tickets is using NestedForm hotness, so new rows are added with javascript and then the whole thing is posted in one glorious datablob. The existing Donations thing (incorporating barcodes) does multi-step: you start the donation, and then add items to it in-flight, and then "complete" it when done.

To convert this properly, the CRLF would have to be captured and prevented, the lookup done over ajax and then the item row built up. I know how to do all this stuff with a normal form, but with the nestedForm stuff I'm just scratching my head. I realized to do it the way I know how to I'd have to tear apart the more elegant (Rails WayTM) solution and make it ugly -- I was hoping there was an elegant way to maintain this without getting crazy and tearing it up.

Thanks for the help, Sean!!! These last couple issues have been doozies!