It seems the gmail account that's viewing the spreadsheet will need write access to generate the label documents. Currently my gmail account does not have permission to write to the ff_labels folder here:
https://drive.google.com/drive/folders/17w2fxSktZ5AIXRlgZukKiQ9dNspBLGKj

1. text form to search spreadsheet (pivot table)
2. update filter on spreadsheet (pivot table)
3. when advancing state, clear filter on spreadsheet
4. have button to reset filter in event of no advancing state

we normally have two printers, one connected to each laptop at the labeling station. i wonder whether we should persist the default filter (odd/even/all) and preferred printer (google cloud printer ID/name) into User Properties.

Sometimes, we have observed that initial calls to the v2 square transaction API does not return the customer ID in the nested tender object. That results in not being able to fetch the customer's name and the name in the spreadsheet row ends up as empty (this isn't ideal...)

we perhaps need to poll that API with some sort of sleep/backoff as we may be seeing replication effects of whatever persistence store Square is using.

to help cashiers view what the order number is, they can currently correlate the last name and total meal count to find the order number. If we added the total transaction amounts ($), that would potentially be helpful.

While most of our Square API calls fetch single objects (or data sorted so that we only care about the first element in the response), as a failsafe we have added support to poll the Square API to find transactions for which we did not process a webhook. Since we are likely to have > 100 orders in one evening, there is a risk that we would not fetch all orders in a single API call.

Therefore, we need to support the pagination API for when we are polling the Square v1 Payment endpoint.

https://docs.connect.squareup.com/api/connect/v1#pagination

Danny Lynch asked me @ Mass this morning if we could stop using the "HB" or "Hand breaded" wording on the labels placed on each Styrofoam container. These terms apparently confuse people working on the delivery lines and using the "fried" moniker would be a better approach.

I think we should leave the menu as "Hand Breaded" but print "Fried".

Dan couldn't see the printers in the "Label Station", but Steve could

in the "worst" case, one of the "admins" will want to make manual edits in the spreadsheet to override errors, etc.

Some of those edits (customer name, meal notes) may need to be reflected in the label document.... we need to add an onEdit trigger to scan the range of cells under edit, and if any cells in relevant columns are touched, we need to regenerate the label doc.

On some labels (take 3-meal order #2503), the first meal label was fine, but the second showed the order ID line for both the second meal as well as for the 3rd meal (e.g. order "2 of 3" and "3 of 3").
The actual generated google docs file for this order looks good; however, there seems to be a problem handling the page break from the google doc when sending to cloud print.

You will note in the google doc for the order that the first label, after the “Fried Combo” text, has two blank lines; while the second label (after "Grilled Cheese” has only one. In the doc, if I just press enter on the line after Grilled Cheese, the label prints fine (even though the doc looks no different), so I think the simple workaround would be to always do the appendParagraph for line5 (the comment), even if it’s just some blank text. Kludgey, but it should get things printing as expected.

E.g. in FormatLabel.gs, just go with:

  var comments = "  ";
  if (notes[mealCount - 1].length > 0) {
    comments = notes[mealCount - 1]

  var line5 = body
      .appendParagraph(comments)

It'd be nice to be able to allow the user to scale these, or have it rendered at 25-50% of the display screen it's being rendered on. It seems the setWidth only accepts integers though, so we'd need to find a way to discover the browsers width at runtime.

Short term fix may be to simply increase the px int passed into this function. It would also be nice to have an object variable to define the width in one location, then have each page read the value from there, rather than having to edit it manually in multiple function calls.

Likely a 'future state' where this could evolve to, after Lent 2018.

It'd be nice to have a consistent repository for some of the values used throughout the code. Is there a decent ORM like SQLAlchemy for JavaScript in the browser or GAS?

Or would it make sense to have different "worksheets" in the Google Sheet for these types of tables, which we could reference in the code?

EnumOrderStates:

possible values

• Order Submitted
• Payment Processed
• Physically Present
• Expedite
• Labeled
• Ready
• Closed

EnumIngredients:

possible values

• Fish
• Shrimp
• Clam Chowder
• Potatoes
• Mac & Cheese
• Coleslaw
• Grilled Cheese

EnumServingTypes

possible values

• Meal
• Side
• Soup

MenuItem

possible values

• Baked Fish
• Fried Fish
• etc.

MenuItemIngredients

Customers

Order

OrderItems

This would be used to determine the number of labels to print, which is currently a count of the number of "meals". Although if someone just orders a side, it should be on it's own label?

OrderItemsInventory

OrderState

Having the data in this format would allow us to do some interesting analytics on the state changes for each order, and let us use the data to help optimize execution in future years.

We are only printing a single digit for meal counts, which isn't sufficient for > 9 meal orders.