So I need to think about what kind of layout i want to have for the dashboard page, and the general workflow of a typical user

• #2
• #3
• #4
• #5
• #6
• #29
• #30
• #31

what's the min info we need to create / make a request?

• requesting store
• customer info (name, address, email, phone)
• request info (qty, description, sku)

also need a db + db route to POST request

• set up a mongo db
• connect to db
• add a route to handle create POST

What should happen after creating request?

• - some ui to let the user know?

What is missing?

• #11
• #12
• #13

• #20
• #21
• #22
• #23

• #17
• #19
• #24
• #25
• #26
• #27
• a seven hills person can securely log into app
• #52
• #49
• #51
• #50

TODOs

• seperate orders to pick with orders ready for ibt / tracking
• add some inputs and button ui
• add db calls to update db with input
• ui improvements

I need to test this with users. There are problems with this screen / business logic currently.

Specific problems i can identify:

• It's not clear to user how many items are left to pick, how many are TODO.
• Buttons should look like buttons, and be disabled when user cannot submit
• Error message should clear
• User should not be able to pick an order which has been already picked?

lt's not clear how to resolve items that cannot be fulfilled.

Also need to think more about the mobile device- how mobile friendly is the page?

user types in a sku, app returns which locations have stock + the qty

the workflow im thinking is user hits a button, goes to a picking / scanning screen. A single list of all the items to pick, and user can scan barcode to pick

• create a context
• create function to save context
• create picking page that gets data from context
• user can scan to pick
  • function to handle checking sku / barcode against picking
    • need something to convert barcode into sku
    • find one request only where sku is correct and it still needs to be picked
    • update this one request only, and update state
    • user can manually "scan" an item without barcde
    • user can undo a scan
  • update context from picking page (or write to db with completed picking results)
    • user can mark an order as short picked.
    • update relevant typescript things (db interface, etc)
• Alert user when a scan does not find any items. (wrong product scanned)

• #35
• what should be on homepage?
• re-do the sections on homepage

i think what i want is a fuzzy search. data set might be around 10k skus?

and the basic version im thinking is: create a search box, user enters in some keywords. some results appear. when user selects desired result, other fields populate (sku, description)

• should i also have a seperate size and colour field? (new fields alongside sku and description?)
  • i think i'll wait for user feedback

updated todos

• create new search box at the top level (above items)
• function to handle search
  • import data from csv into sql
• display results
• populate fields when user chooses a result

so how to handle this with state etc?

on the request ive got the below fields. so i could put the store address in the address field. or add a new property saying something like

storeOrDirect: "store" || "direct"

export type IStoreRequest = {
_id: string;
name: string;
phone: string;
requestingStore: string;
email: string;
address: string;
items: Item[];
status: "new" | "issue picking" | "ready to post" | "posted";
ibt: string;
tracking: string;
updatedAt: string;
};

when a single request has multiple items with the same sku, each individual item is marked as scanned. Only one of the items should be incremented as scanned. Increment and decrement buttons also have this bug

Right now, some text below the button tells user if it was successful or not.

Should the form clear / page refresh if it was successful? Should the store have a dashboard to view the request?

just do 1 simple card based for seven hills. view all todos.

why does seven hills need a dashboard?

• to give a sense of control to user; this dashboard will tell user that there's some work
• there needs to be a place to see everything

What info is important to show in the card?

• the requesting store
• customer name (something to help identify requests.
• items

some layout ideas:

• Accordion List
• nested list
• Card-Based Layout

todos for this issue:

• handle getting the requests
• display requests