jaikamat / clubhouse-pos-importer Goto Github PK

The shop is now open for business 7 days a week. Unify the message from discord.

Steps to reproduce:

• Unsuspend a sale
• Attempt to print a receipt
• The printer spools paper infinitely until manual intervention is required

Current fix:

• The user adds and removes a card from the suspending sale, and the receipt prints as normal

Notes: There might be a DOM artifact lying around that creates a style of variable height

Currently we interpolate the username and password for the mongo connection URI in gc_functions/updatePrices/mongoBulkImport. Move all this data to a dotenv .env file for added security and ease of use via crontab.

We should still be getting the database name from the user to differentiate between test and production collections.

Clicking 'log out' in menu should sign the user out immediately, rather than the two clicks it currently takes to log out

• Edit e2e tests for this feature, as logout workflow has changed

Customers currently can only search for cards based on title. We should be allowing customers to search based on certain qualities, such a borderless/EA art, foil/nonfoil availability, and other parameters.

Circle back with staff to determine what customers ask for most, and what search features could be useful to them. Also, think about general keyword searches, not exact title searches.

Due to spikes in demand for recent cards, use a new pricing provider or scraper for displaying prices to customers under the Search tab. Right now we're using TCGmarket, should be using TCGmedian.

Can we mock out a testing database to create integration tests for the interactors?

This should be created and destroyed before and after the runner executes the suite.

We need to remove these errors in one shot on a quiet day while a manager is on duty. Single-removal adds too much user overhead; the inventory is not kept up to date

When users currently re-suspend a suspended sale, we delete and re-suspend the sale client-side. We need to be doing this backend, passing through an ID via params if we want to overwrite (edit), and no ID if we want to create a new suspendedSale.

So that users don’t have to make changes by going through engineering

Leaving it flush with the viewport on both top and bottom is a little jarring.

Receiving is a hot mess of tightly-coupled and prop-drilled top-level component methods. It could use a refactor to make the base more maintainable and extensible for (inevitable) updates going forward.

Staff currently see items like CARDNAME | NONFOIL_NM | QTY: 1 on line items when fetching inventory for customers. Printed receipts also need to highlight the border treatments (alternate or Godzilla art) as well for clarity.

border_color: borderless and frame_effects including the string extendedart should be supported so staff can field these requests from customers.

A sad day, but we gotta tell people about it.

Buylist component shows the number of cards currently in the list, this functionality should be carried over to the Sale list as well.

Suspend Sale component is a beastly, tightly-coupled top-down component consuming a ton of props. Pull these suspendSale API methods into each of their respective handler subcomponents.

After ten minutes of idle time, a user should be logged out and redirected to the login page

The inventory entities remain untyped, which may cause frustration in future feature releases. We should be typing them via an ODM or through Typescript classes to coerce, for more stability at compile-time

Customers should see not only cards lower than 50 cents at 50 cents, but also all cards should be rounded to the nearest 50 cents.

Always round to the nearest 50 cent price on any view that faces customers.

ex. $1.18 => $1.50
ex. $0.18 => $0.50

Users should be able to suspend receiving of cards in-progress.

Implementation: Store suspended array in mongo tied to a UUID.

Scryfall will soon implement bulk pricing! This will greatly improve lookup speed on the deckbox clone method, getCardsByFilter.

We should be refactoring the aggregation pipeline operations to pull directly from the prices property on bulk data rather than performing a $lookup on the scraped pricing collection.

Users have to search for each card by title, which is a cumbersome way to view sales. Create one endpoint that retrieves the day's singles sales for at-a-glance reporting, and refactor the existing getSales endpoint to retrieve single cards. Both endpoints should expose more data about the sale, price, id, etc for use cross-platform ins Lightspeed POS.

Employees are unable to view quantities on Receiving, presumably to to the InventoryCard class being unable to translate QOH properly.

We need to be able to add cards to the inventory that have names with fewer than three characters.

This will pose challenges to querying the scryfall API with short titles

Customers should be able to access and search through a store-defined buylist.

Note: should this part of #94?

When we fetch cards with getCardsByFilter, we merge objects in both the card_inventory and scryfall_bulk_cards tables by using the $replaceRoot functionality in the Mongo aggregation pipeline. However, some cards have legalities within their inventory entries because of legacy persistence functions, and these legalities conflict with the newer, fresh bulk legalities - $replaceRoot does not replace them. Because format legalities are mutable and may change over time, we should look to $unset only legalities in the card_inventory collection.

• $unset the legalities property in the card_inventory collection in the test db
• Write testing to confirm that getCardsByFilter works as expected
• $unset the legalities property in the production inventory collection

Need to create a .env file to manage the mongo connection URI, and ensure the update prices function doesn't hang. Perhaps scrape/bulkUpdate in batches to avoid memory-space issues.

• Refactor the updatePrices main function to scrape in batches
• Refactor to bulk update in batches
• Reinstate daily cron tasks

There must be a selector in the colors dropdown that allows users to query the inventory for a list of cards with two or more colors in their mana costs.

Select 'multi' for a list of all multicolored cards, which deselects and overrides all other color selectors in the React form. Then collate a list by checking for cards with more than one color in the colors property on the backend.

This goes deeper than we'd thought. May have to make some drastic changes to the db layer and how data is stored/retrieved. The ultimate source of truth should be Scryfall's bulk data file. Currently, when inventory is added, we are copying a data source that may/may not mutate over time, into the inventory collection.

What should be happening is, we should make a collection of just QOH and other store-relevant properties tied to an _id property, and use the aggregation pipeline to "zip" these up, especially when retrieving cards for title queries and altering inventory.

We can test this in development - start thinking about just the Manage Inventory view and routes, and what changes will propagate out site-wide.

Possible low-hanging fruit: Some React components rely on either GET_SCRYFALL_BULK_BY_TITLE or GET_CARDS_BY_TITLE. Unify these by aggregating them against available inventory and scryfall_bulk_cards into their own endpoint GET_CARDS_AND_QOH (don't alter the database yet). Test them thoroughly within their necessary components.

Then, migrate the inventory data to a suitably concise and compact model. Something along the lines of:

{ _id: <id>, qoh: <qoh_object> }

Originally posted by @jaikamat in #8 (comment)

Staff need to be able to:

• Add and remove foreign language cards
• Sell foreign language cards

Customers need to be able to:

• Query and view foreign language cards

Todo:

• Add a language dropdown to the staff search bar in all views
• Alter the getCardsWithInfo endpoint to receive a language filter. If language is provided, filter on that language. Otherwise if not provided, retrieve all cards.
• Default the UI to English for all views
• Test queries for time and efficiency, and functionality

Notes:

• Download the scryfall all-cards bulk and upsert that (alter the upsertion script)

• Ensure the scryfall _ids are all the same

• Ensure the get function retrieves cards as normal

• Edit the backend function to filter on language if provided in queryparams

• Stream the and filter all_cards bulk into separate language files by filtering on language property, then update to the database using the new upsert file

• One script for the default_cards, one script for language support. Should save the json as scryfall-bulk-language-<lang>.json and take in params of lang for language to parse out and write

• Add "language" label to all card headers to show the language of the card in the event of no image available

• Add the lang property to the ScryfallCard class on the frontend

Core 2021 booster box preorders are over, so those should reflect the $110 price point. Collector boosters stay the same until July 3rd.

When receiving cards, we currently map over the receiving list of cards with promised calls to addCardToInventory. Any failures within the Promise.all will not be rolled back. We need to create an endpoint that takes in a list of cards, increments each one in the database, and returns a list that was persisted for frontend use so this is not managed client-side.

API endpoint receiveCards should:

• take in an array of scryfallCards
• $set and increment the quantity received
• insert card documents that do not exist in inventory yet

We shouldn’t be doing this manually when each set releases

Sale components are extremely tightly-coupled around top-level state management and prop-drilling, which makes testing individual component testing difficult outside of e2e tests. Decouple the view from its corresponding model by using the context API and Hooks.

Prices for the whole dataset take about 5-6 hours to scrape politely. We should not be executing this script and pushing it to Mongo manually.

Using the Google VM, write a cron task to execute this script once or twice per week. Refactor the script as needed, too!

Cards with the Devoid attribute are sorted as colorless, despite having colored pips in their casting costs. Presumably because Scryfall (rightly so) designates these cards as colorless. Will have to explore the data for other options to identify cards with Devoid correctly.

Users should be able to see a component that displays total inventory for any one card across all printings, for each store location

The current landing page is not designed with UX in mind - gather some reference to make it look nice and clean, modern, etc.

We need a history of buylist records. Customers may want to know what they were offered if the trade was store credit.

We need to see the prices that singles were sold at (per item).

We should also include the employee metadata if possible.

Users should be able to hover on line-items to see the image previews of cards, rather than relying solely on title and set data to inform them (this is especially true in the current climate of alternate art printings and variants).

• Sale list should show images on title hover
• Receiving list should show images on title hover

New updates to product and sales, new offerings. Update the front page.

Customers should be able to create their own sale tickets, to be viewed and fulfilled by Clubhouse employees. Brainstorm a workflow and edge-cases for implementation. This will likely be a large, comprehensive feature spanning multiple fullstack services.

Users currently can't differentiate between Borderless, Extended, IP Series, or other special treatments across cards in Receiving.

• Expose these properties to the receiving components
• Perhaps add an image hover over title to allow users to see the actual cards rather than descriptors
• Add a sufficient amount of e2e testing coverage

Linking #26 here, because it could use a refactor prior to making the change.

When a user clicks 'Finalize Sale' and then 'Yes', the searched-cards (on the left) are not cleared and their inventory values not updated, which may lead to edge cases when the same card is sold back-to-back. Users choose the incorrect quantity to sell, and thus are unable to fulfill an order in its entirety.

Clear the searched-cards by integrating them into the SaleContext emptying the array on sale submission.

Useful data would be cards searched for by customers which yield no results. Would allow staff to place orders that directly target in-store demand.

This should ideally be placed in the 'Reporting' feature and allow users to set a variable time frame.

Implementation could be as easy as tacking on a resultQuantity: <int> message to each getCardsWithInfo log and querying the logs API somehow by resultQuantity: 0 to then collate, filter and yield. Odds are it'll be far more involved than that.

Users cannot currently search by rarity. We need to allow users to multi-select by rarity, any number of rarities from among c, u, r, and m.

Refactor the mongoImport script (which updates bulk files) to instead use the bulkWrite API.

There will be some conflicts transitioning from using the natively-assigned ObjectID() to the Scryfall id, most notably in $lookups and perhaps some frontend components that require the card _id