design cellar item workflows

[lukeforehand]

Entering items into the cellar is the main workflow
Enter Cellar Item Storyboard

Add cellar item:

• scan UPC code to find beer details OR
• search for beer details
• if UPC lookup fails, resort to search
• if search fails, user can enter new beer details for us

Add new beer:

• add beer details
• save

Search results:

• either a UPC code scan, search, or add new beer was successful
• choose quantity of items and proceed to confirmation OR
• choose to label bottles and scan QR labels

Scan QR labels:

• user labels each unlabeled bottle with a QR code
• QR codes will be unique so user can print several pages of labels in the beginning to use
• scan QR code for each bottle in the package
• proceed to confirmation

Add item Confirmation:

• verify entry details and save
• if a UPC was scanned and a different or new beer was associated, record this in our system

[lukeforehand]

Please discuss the issue where a user wants to edit a batch of items by just scanning a single bottle from the package (batch). Maybe we maintain a batch field in the cellar item entity, then we can lookup the entity via scanner, then perform update on all entities matching the unique batch field of the scanned entity. the batch id can be autogenerated by the application.

[shyCordial]

I think the batch only makes sense if there will be multiple occasions on which the user will want to make the exact same modifications to each bottle/unit. That might be a bit complicated if one or more of those bottles has been edited individually since the batch was created (i.e., conflicting data - do we override the existing data, ignore the record entirely, or try to merge the two values? The former is icky when we have a single-response item with discrete values.)

An alternative is to provide a copy/duplicate (verbs!) feature or a template feature.
Once I have entered all of the details for a single bottle/unit, I can opt to duplicate this unit record into x NEW additional unit records (each with a unique ID/QR code, but all other data duplicated from the master/parent unit). Then labels can be printed for all of the bottles/units. If we want to link the duplicate units in some way to track that they were from the same case, that could be done at the same time or later on, perhaps with a unique "set" identifier.
I suppose if you already have labels for each unit/bottle you can opt to duplicate the data into existing bottle records instead of duplicating the record into new records; in that case, we would overwrite any existing data in the existing records.

Template is similar, except that instead of being included as a unit/bottle in the cellar, it's a pre-populated/saved set of data that can be applied to new units. This would be nice for users who regularly purchase or brew the same beer (brand & style or recipe), as a template will save the user time/effort, and can be used indefinitely.
One enhancement I can envision for the template idea is an ad-hoc item-override feature, so that certain items/attributes can be set to a different value each time the template is used - said items can either be left blank in the template, or be populated in the template and simply replaced with the ad-hoc value when the template is used to create a new item(s). A few examples of items a user might override: date acquired; origin (where or from whom the case/item was acquired); expiration date; fermentation time; container type.

[lukeforehand]

I think the ability to edit the batch of items would be allowed until a bottle leaves the package. Once a bottle leaves the package it would be difficult to manage batch edits. We can record when a bottle leaves the package. There are two events that should be recorded, either a bottle is given to another user or it is drank (reviewed). I believe we can then query the system to determine if a batch is still editable by examining the cellar_item:reviews object or the cellar_item:previous_cellars object. It won't be perfect to start but I think it is good enough. I'll add this requirement to the description.

[shyCordial]

But I could edit a bottle in the package at any time without it leaving the package (i.e. giving it to someone else or drinking it), which would put it out of sync with the other bottles, and opening it up to conflict if the batch is edited.
Also, others reason a bottle would leave is if it started leaking, or got broken, or needed to be split off simply because it doesn't fit in the space... it seems to me that there are more than 2 events that should be recorded (see the Flows/Requirements document in our shared Google drive).

[lukeforehand]

Editing an item really means modifying things like brewery or beer name, things that are common across the package. In other words we only want to allow batch edit for details that come from the package itself, meaning if you do edit this information you want it to apply to the entire package for convenience sake and because you are changing information that should have been static and unchanging in the first place. A general rule for editing a batch (package) would be that only items still owned by the editing user would be updatable.