cander / booze-hound Goto Github PK

View Code? Open in Web Editor NEW

2.0 2.0 0.0 426 KB

Ruby 72.52% JavaScript 0.86% CSS 0.51% HTML 23.22% Dockerfile 1.57% Shell 1.32%

booze-hound's People

Contributors

Stargazers

Watchers

booze-hound's Issues

Replace FontAwesome link with Booze Hound account version

Background

We're currently using Kenny's FontAwesome profile for Flash Chord as a temporary solution, but we need to setup an account on FontAwesome for Booze Hound, which is free for what we'll need.

Acceptance Criteria

A FontAwesome account is setup for Booze Hound
The FontAwesome include references are updated to use the Booze Hound account
The FontAwesome account is configured to limit use to the Booze Hound domain(s)

Approach

Wait until we have a domain and email setup, then use an email address to create a free FontAwesome account
Setup the FontAwesome account and configure it for Booze Hound domains only
Up date the JS references in the foot include to use the Booze Hound account version of FontAwesome

Notes

This is technically not needed for functionality, but it's likely a terms of use issue that we should resolve.

This is dependent upon #79 as we need the vanity domain to setup email and then we can use that email to register the (free) account with FontAwesome.

Allow for toggling between light- and dark-mode UI

Background

Many modern sites allow users to

Acceptance Criteria

Users, both account holders and casual, can select from light-mode or dark-mode themes
The setting is saved across sessions (depending on the answer to the questions below)

Approach

Use Bootstrap's dark mode color scheme changes and JavaScript to toggle between the two
(See questions below) ...and store the setting as needed

Notes

Questions:

For casual users who simply search, do we want to store the setting on the user's compute with a cookie so they don't have to re-set it each time?
For users with an account, would we store this in the user profile?

Add issue template to .github directory

Background

There is currently no template for GitHub issues (feature request and bug), so we should have templates for easy issue creation. :)

Acceptance Criteria

A template exists for GitHub issues (feature requests and bugs)
Charles has approved the templates and the PR is merged into main

Approach

Create issue templates for feature requests and bugs in /.github/ISSUE_TEMPLATE:
- feature-request.md
- bug_report.md
Commit/push to the github-config branch and issue a PR into main

Notes

Public release notes and changes page

Background

To keep users informed, we should setup a page (or section of a page) with a list of updates to the site (like a mini blog) with changelog posts.

Acceptance Criteria

A page (or section of a page) exists with a list of site update posts that can include changelogs in the body, when appropriate
Each post contains the following fields:
- Title
- Date published
- Published status
- Body
- Author (this may not be necessary as author can just be "admin" or "Booze Hound" or "Tipsy McStagger")
- Images (we may want to attach images to reference changes)

Approach

Decide where update posts and changelog messages should be posted
- ...probably a subpage of About
Create a method for publishing posts with the fields mentioned above, but this can be manual via code push rather than a web interface for authoring as we'll be the only ones publishing these and it will (probably) coincide with a production push of code changes anyway

[UI] Create profile page - read only mode

Background

Belongs to #124.

Our users need a profile page for displaying their user information. Edit mode will come later.

Acceptance Criteria

A user profile page exists that displays
- User name
- First name
- Last name
- Email
- Followed bottle categories
- Link to followed bottles
- Link to followed stores

Notes

For later implementation:

Home zip code
Search range (distance from zip code in miles)

Update dependencies, including Rails 7.1

Background

Update all the dependencies to the latest versions. Normally, I don't bother with a ticket, but Rails might be a big-ish issue.

Acceptance Criteria

All dependencies are updated.

Approach

Dependabot has already opened PRs for most/all of them.
I don't think Rails 7.1 will be a problem, but we never know. It's been 2 years since 7.0
Look at the current version of Ruby, while we're there. Version 3.3 will come out at Christmas, but we won't jump on it immediately.

Notes

Prototype new UI

Background

The site has been created without any specialized UI, so we need to develop a full UI/theme. The first step will be to create a static prototype before breaking it up into components and using Ruby's templating framework.

Acceptance Criteria

A (possibly temporary) logo exists
A static HTML prototype exists which:
- Themes/styles the overall page wrapper for the site
- Themes/styles the content for the existing pages on the site
Charles has approved the static UI prototype
An issue has been filed to implement the new UI as Ruby templates

Approach

Use the ui-dev branch with the /tmp/ui-dev/ directory for development
Use Twitter Bootstrap 5.3 with CDN links (i.e., not built-via-NPM)
Review with Charles for approval
File a follow-up ticket for templatizing the new UI with Ruby's templates

Uptime monitoring

Background

We want to know if the application is having issues preventing users from using it. Do we need uptime monitoring for the application or is Google Analytics (#72) sufficient?

Acceptance Criteria

Uptime monitoring with alerting is configured for the application

Approach

Determine if we need uptime monitoring in addition to GA4
- If yes, implement uptime monitoring with alerting (email, text, Slack?)

Add the ability to list all bottles in a category

Background

We should be able to list all the bottles in a category (e.g., rum) for browsing. It's an easy query.

Acceptance Criteria

There's a button (or other control) somewhere to click to get the list of bottles, sorted by name.

Approach

Add an option to the index method of the controller. (That method is getting kinda crowded.)

Notes

The possible rub is that I feel like the bottle listing is getting overloaded. Originally, we just listed the bottles a user followed. Then I added the ability to search by name for bottles and get a list. Then there's list ticket, and #107 will add the ability to add a bottle in a category we're not following. I feel like we're adding lots of bottle functionality in a very haphazard manner - I'm just hacking it in wherever my limited HTML skills will allow.

RSS feeds for bottles, stores, distillers, and user's feeds

Background

Users may wish to subscribe to an RSS feed to get updates for new bottles, new stores, and new distillers so they don't have to actively check the site. Similarly, users may wish to have an RSS feed for the specific things they follow.

Acceptance Criteria

RSS feeds exist for:
- Bottles
- Stores
- Distillers
- User's favorite bottles
- User's favorite stores
- User's favorite distillers
- Booze Hound updates/changelog (see #74)
Non-user-specific feeds are published on the site
User-specific feeds are technically public, but they include a UID in the path and the paths are only published on the user's page when signed in

Approach

Create RSS feeds for bottles, stores, distillers, Booze Hound updates
- These are published on the site in completely public locations
Create RSS feeds for user's favorite bottles, stores, and distillers are published only on the user's personal pages with a path such as booze-hound.com/user/[some user ID]/feeds/bottles
- This may imply the need to create a page under the user's profile section for feeds or maybe we just include the links on some other page

Get Docker running for development environments

The goal is to have a one-step command to build and run the app in a Docker container. @KCarlile created the origin/docker-local branch with an initial cut from his projects. Get that working for real. Issues include:

The Dockerfile is hard-coded for the production environment (for fly.io). We want to build an image for development.
Related: the bundle install should include development and test libraries
The Docker compose needs to mount the database file into the running container.

Implement real multiple users and login

Background

The modeling of stores and bottles is all in terms of the User model, but there isn't any way to support multiple users - i.e., no way to login as a different user. Right now, everything is based on the first user in the DB.
Adding this will make the app more "secure" out on the internet.

Acceptance Criteria

The system supports multiple users that are selected by logging in, like a real app.

Approach

Start by looking at the Devise gem.

Notes

[Epic] UI pre-launch improvements

Background

This ticket is effectively an epic for UI changes in the pre-launch phase (for Milestone v1.0).

Tickets in this Epic

#125
#127
- 🔗 #128
#131
- #126 (provides /user page and path needed by #131)
- 🔗 #122 (not a hard dependency)
#140
- 🔗 #139
#141
- 🔗 #123
#142
- 🔗 #122 (and maybe another)
#147
#152

Update README.md with technical details

Background

The README.md file has very little detail and could be updated to include meta data, product data, and technical data.

Acceptance Criteria

The repository's README.md is updated to contain:
- Meta data
- Product information
- Technical information

Approach

Meta data should include:
- Author/owner
- Contributors
  Product information should include:
- Product description
- Vision/intent
- Scope
  Technical information should include:
- Dependencies (Ruby, SQLite, Twitter Bootstrap, jQuery, etc.)
- Local development setup
- Hosted setup for dev and production
- Domain/DNS
- Deployments, CI/CD setup

Support paging of recent events

Background

Allow the user to see more than one page (20) of commits.

Acceptance Criteria

The UI allows the user to page forward and backward through events
Does this need some sort of request/controller spec?

Approach

Add an optional parameter to the GET request for the home page that includes the page number. (For the time being, we will just rended the whole home page again, but in some plastic-fantastic world of JavaScript there would be a separate controller for the events, and the home page would hit it to fetch just the events.)
Add next/previous links to home page to page through the events. Don't bother with a count of the number of pages.

Notes

Should the number of results per page be configurable by the user?
- Maybe that's a v2.0 feature for which we can file a ticket once this is done.

Design information architecture

Background

We need to understand the structural elements of the site from the user's perspective, so we should design the information architecture with intention.

Acceptance Criteria

A hierarchical map of the site exists to inform navigation and information architecture
- This design should include all navigable pages for the user and administrators
  - In the case of dynamic pages, such as store or bottle listings, a placeholder can represent all of those individual pages

Approach

Build a visual representation of the site's information architecture including user pages and admin pages
Some indicator should specify which pages are placeholder/template pages that represent multiple pages, such as for stores, bottle listings, etc.
This information architecture design will inform the UI/UX design

Notes

Use Mermaid Workflow diagrams (see this GitHub page about Creating Diagrams)
This is not a sitemap (visual) or sitemap.xml (text-based for search engines)

Information Architecture Diagram

Home

graph LR;
    Home-->About;
    Home-->Login([func:Login]);
    Home-->SignUp([func:Sign-up]);
    Home-->Find;
    Home-->Stores;
    Home-->Bottles;
    Home-->Brands;
    Home-->Admin;
    subgraph groupAdmin["Admin Content"]
        Admin-->MngSettings[Manage Settings];
        Admin-->MngUsers[Manage Users];
        Admin-->MngBottles[Manage Bottles];
        Admin-->MngStores[Manage Stores];
        Admin-->MngBrands[Manage Brands]:::future;
    end
    Home-->User[User Profile];
    subgraph groupUser["User Content"]
        Login-->User;
        SignUp-->User;
        User-->Settings:::maybe;
    end
    subgraph FindBrowse[Find/Browse]
        Find;
        Stores;
        Bottles;
        Brands:::future;
        Find-.->Stores;
        Find-.->Bottles;
        Find-.->Brands;
    end
    subgraph "Stores"
        Stores-->MyStores[My Stores]:::user;
        Stores-->AllStores[All Stores];
    end
    subgraph "Bottles"
        Bottles-->MyBottles[My Bottles]:::user;
        Bottles-->AllBottles[All Bottles];
    end
    subgraph "Brands"
        MyBrands[My Brands]:::user;
        AllBrands[All Brands];
    end
    subgraph "About Content"
        About-->Updates:::maybe;
        About-->Help;
    end
    Stores[Store Listing];
    Brands[Brand Listing]:::future;
    Bottles[Bottle Listing];
    classDef maybe stroke:#ffa500,stroke-width:2px,color:#fff
    classDef future color:#fff,font-style:italic;
    classDef user stroke:#0000ff,stroke-width:2px,color:#fff
    style groupUser fill:#00001a,stroke:#0000ff,stroke-width:2px
    style groupAdmin fill:#1a0000,stroke:#ff0000,stroke-width:2px

Legend

Style
- Italic: some future state
Colors
- Orange outline: could be done in this phase or in some later phase
- Blue outline: user content
Shapes
- Rectangle: page
- Round: function
- Rectangle with ends: link
Groups
- Blue background: user-authenticated content
- Red background: admin-authenticated content

Daily update should update "random" bottles

Background

The daily update process will update all bottles in the categories that were are following. Feature #107 makes it easy to add bottles that aren't in those categories. Such bottles would not be updated daily - e.g., price or description. (Inventory will still be updated.)

Acceptance Criteria

All bottles, including random ones, will be updated daily.

Approach

Could create a new method to identify randos (outside the tracked categories) and update them.
Alternatively, it could be done during inventory if the bottle isn't in a tracked category. But, that blurs the inventory update.

Notes

Repository protection

Background

The Booze Hound repo should be configured properly to protect against mistakes.

Acceptance Criteria

The Booze Hound repository and its branches are protected against accidental or malicious changes and enforce the correct procedures for development and contributions

Approach

Ensure that the main branch is protected against direct pushes without going through a PR
Ensure that PRs require review prior to merge
Ensure that any other security/permission issues are properly handled

[UI] Create login and sign up pages

Background

Belongs to #124.

Once we have the user functionality setup correctly, we'll need pages for creating accounts and logging in to the system.

Acceptance Criteria

/user/sign-in exists for users to login (username and password) to their existing account with links for forgot username and forgot password
/user/create exists for users to create an account with the following fields
- First name
- Last name
- Email address
- Username
- Password

Notes

This technically relies on #122, but we can wire up the functionality later.
See #68 for page structure/information architecture.

Application logging

Background

We will need the ability to review logs for the application, not just the dependencies (Ruby, Rails, Apache, SQL, etc.) in order to debug issues or audit activities.

Acceptance Criteria

Application logging is available to admins
Page-level logging in the UI is available for admins only

Approach

Application logging should write to log files on the server
Page-level logging should also be written to a collapsible textarea on the page that is visible only to admins when logged in

Sort user's favorite stores

Background

Sort the list of the users favored stores. It's currently unordered.

Acceptance Criteria

The list is sorted.

Approach

Create a service object for the query so that it's easy to mock. See bottles.

Notes

Add any additional notes go here, such as reference links.

[UI] Replace faux-auth/anon functionality with real auth check

Background

Belongs to #124.

The auth/anon content is faked right now, but we need to clean that up.

Acceptance Criteria

Auth/anon UI guidance is removed, including red and green borders
Auth/anon split leverages faux-auth-check function to be created

Notes

Charles to create a function for a faux-auth-check to use in the UI in #128

Bottle detail page should include the category

Background

It's usually obvious what category a bottle is (rum, domestic whiskey, etc.), especially for a booze hound using the app. However, I found an oddball new bottle, that's probably a rum, but I'm not sure. It's easy to add.

Acceptance Criteria

The category is display in the (currently ugly-ass) bottle detail page. Ideally, it wouldn't be ALL CAPS.

Approach

Add it to the show ERB file.

Notes

Docker dev workflow is broken in DB migrations

Background

Running server-cal.sh loaddb blows up running migrations.

== 20231004202603 AddFollowersCountToOlccStores: migrating ====================
-- add_column(:olcc_stores, :followers_count, :integer, {:default=>0})
   -> 0.0059s
== 20231004202603 AddFollowersCountToOlccStores: migrated (0.0059s) ===========

== 20231005212011 InitializeStoreFollowersCount: migrating ====================
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

undefined method `favorite_store_ids' for nil:NilClass
/rails/db/migrate/20231005212011_initialize_store_followers_count.rb:9:in `up'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:908:in `public_send'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:908:in `exec_migration'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:889:in `block (2 levels) in migrate'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:888:in `block in migrate'

Destroying the DB and rebuilding it from scratch seems excessive. There should be a way to just update the DB. Dogmatically, we should always be able to rebuilt everything from scratch, but it shouldn't be required.

Acceptance Criteria

The loaddb command works correctly.
Look at the developer workflow. Do we need something better?

Approach

This smells like an issue with ordering migrations. OTOH, it works/worked fine in test. Why is it breaking now?

Notes

Determine business model

Background

What is the business model for this site? F/OSS? Ad-supported? Paid membership for users? Paid membership for stores and distillers? The state-run data aspect of this complicates it somewhat.

Acceptance Criteria

A business model exists for this endeavor which may or may not include revenue

Approach

Research and discuss possible business models
Determine the best approach and assess feasibility (including legality)
- If F/OSS, create a ticket to implement a license in the repo
- If any other models, make the repo private
Implement the business model

Notes

Possible models:

Model	Pros	Cons
Free and Open Source Software	Feels good, no complications	No step 3 (profit)
Advertisements - Google	Easy to setup, if it passes checks	Probably wouldn't pass checks due to alcohol and state
Advertisements - Solicited	We decide who advertises	We have to become sales people
Paid user membership	Volume model	Critical mass required to see profits at volume
Paid store/distiller membership	Deeper pockets	We have to become sales people and these are harder to sell
Others ideas...?

Add a link from an inventory event to the store

Background

We create events for new bottles as well as bottles arriving at stores. When a bottle arrives, the message is arrived at Dallas. The name of the store (Dallas) should be a link to the store.

Acceptance Criteria

The name of the store (Dallas) should be a link to the store.

Approach

Just add the link to the home page's view. One line change.

Notes

Follow up work from adding bottle by ID

Background

While working on #107, I found a couple of things that I wanted to fix, but I wanted to just finish that ticket.

Acceptance Criteria

Add error message function to AppService
Remove the old_item_code from the API client and LoadBottle because it doesn't seem to be needed.
Convert exceptions from OlccWeb to use a custom exception class rather than string.

Approach

Notes

My scrawl notes about the error message:

  # error_message
  # error_message=(msg)
  # reset_error_message
  # The key is class name + error_message
  # Hitting Thread.current[key] - thread-local variable

When looking at a bottle you don’t follow, make an inventory request for it

If you don't follow the bottle, there shouldn't be any inventory records for it (especially while the system is still single user). It's not really helpful to say it isn't in any stores. So instead, make an inline call to OLCC to fetch the inventory using the existing library function. Don't persist the inventory records retrieved.

Note: this will be "slow" to make a synchronous request to OLCC. That's fine for the moment.

Model per-user categories

Background

At the moment, we only track two categories (domestic whiskey and rum) because that's all I care about. Eventually when there are multiple users (e.g., after #122) different users will have different preferences.

Acceptance Criteria

There needs to be a relationship between User and the categories of bottles. It's not a real M:N DB relationship because categories are an enum rather than a table. (There's no need to change that.)
A user only sees new bottle events for categories s/he cares about - that's the primary driver
The daily job currently hard-codes the two categories we follow. That needs to moved to function that selects all categories followed by all users.
This ticket does not require a UI to configure the categories for users. Let's handle that later as some sort of user preference.

Approach

Could remove the hard-coding into a method as a first baby step.
It's not a real M:N DB relationship because categories are an enum rather than a table. (There's no need to change that.)
We can test this all in unit tests (different users with different preferences), but we'll need a way to configure the User's categories in the DB somehow.

Notes

Audit and refactor app paths

Background

Paths such as /olcc_bottles/ and /olcc_stores/ are not very user-friendly or SEO-friendly and we probably don't want "OLCC" in the path. These, for example, should just be /bottles/ and /stores/ or something like that.

Acceptance Criteria

App paths make logical sense for users, SEO, and desired terminology/nomenclature
Any non-conforming paths are refactored

Approach

Audit the app's paths and determine which ones need to be modified
Refactor app paths as necessary
- /users/profile --> /user/profile
- /user/1 --> /user/

Notes

...

Fix user data formatting

Background

<%= @user.first_name %> prints charles, but this should print Charles.

Acceptance Criteria

User fields are formatted properly, including:
- First name
- Last name
- (Any other fields that we have right now that need proper formatting)

Notes

Kenny has removed the capitalize() function from the home page where it used to be <%= @user.first_name.capitalize() %>, so this is now relying on proper capitalization from the user object. (That will be changed in #125.)

Inventory for Hayman's Old Tom gin is wonky

Background

I follow Hayman's as a one-off (we don't follow the gin category). As of 9/18, the bottle details says it's not at any stores, and the detail for South Salem (olcc_stores/1198) doesn't list the bottle. However, the OLCC site says there are 4 bottles in South Salem. What gives?

This seems like it's related to #56

Acceptance Criteria

Bulleted list of what would constitute this bug being resolved

Approach

Bulleted list of steps to take in order to achieve this feature

Notes

I don't know if it's related, but last nights daily run
https://github.com/cander/booze-hound/actions/runs/6221168450/job/16882616552
Says

There are now 0 new inventory records

Clearly, there are inventory records.

Data error for Eagle Rare and 1792 Small Batch

There is a data error for Eagle Rare and 1792 Small Batch (in production, at least) where the app reports there are no bottles at my store, but there are bottles (or at least there were at the time I saw the issue - Eagle Rare is no longer in Dallas.)

As of 8/25/23, there 1792 isn't in any stores, but it's available in Dallas, Independence, and several Salem stores.

To handle it, probably need to open a console to production (document that in operations.md if it isn't already) and run queries. Might be able to duplicate it locally. Try to figure if there are other bottles affected.

Check the daily job. Do we have any/enough log output. If not, create another issue for that.

Setup Google Analytics (GA4)

Background

To track site usage, we should setup Google Analytics (GA4) on the site in Production.

Acceptance Criteria

GA4 has been setup for the production site
Dev and local environments are excluded from tracking

Approach

Wait until we have the site on a www.vanity-domain.whatever
- This may also require configuring ownership of the property in Google Search Console
Setup GA4 for the production site (www only) and that dev and local environments are excluded from tracking
Ensure that Kenny and Charles both have access

In the detail view of a bottle, the stores should be sorted

Background

Just go into any bottle that's carried in several stored and look at the list of stores.

Acceptance Criteria

The stores are sorted alphabetically increasing
No need for any user control of it (yet)

Approach

Add an order clause onto the SQL.

Notes

[UI] Improve mobile experience for My Links submenu

Background

Belongs to #124.

In mobile view, the My Links submenu drops below the main content, which is undesirable.

Acceptance Criteria

User links (those from My Links) appear in a main nav dropdown ✅
User link (just the top-level) also appears in the footer nav ✅
"Become a Hound" signup is moved above the main nav for the anonymous page ✅

Create a way to add a bottle using just the bottle ID from OLCC

Background

To keep the scope, resources, and API calls to a minimum, we currently only follow two categories of booze: rum and domestic whisky. So, those are the only categories that create events about new bottles, and we can only search for bottles in those categories. Sometimes there are bottles that I'm interested in beyond those categories - e.g., a gin or liqueur.

In the very short term, I'd like a hack to just add a bottle. I have a command line tool to do that, but I'd like to do it from the web, in part because getting to the console for the production system is a slight challenge.

See the notes below for a larger discussion of the functionality and options.

Acceptance Criteria

Just add an input of the favorite bottles page to add a new bottle by ID.

Approach

The controller can call the same code to call OLCC that the rake task uses - it should be in a service object, move it if not.

Notes

Thinking about this in a larger, non-hacky scope:

I could just load all the bottles from all of the categories now, but only fetch updates from the same categories I do now. That would allow me to find a gin or tequila I care about today.
In the end-state, we should be following all categories, but I don't want to be inundated with events about categories I don't care about.
- That implies that a user should have the option to follow/unfollow categories.
- When events are shown, they should be filtered by categories that the user follows. So, the events would need a category on them (which would be denormalized) or the query needs to join events and bottles to filter on the bottles' categories. (I think there's an include from event to bottle - should be a join.)
This (adding bottles from "foreign" categories) could be an admin function now, but in the end-state, we'd be following all the categories, and it would just be automatic. We could make it an admin function for now, but we have nothing in place for admin operations.

I'll think about this a bit more before acting on it.

Setup linting

Background

The Booze Hound repository should perform linting for the languages used to ensure best practices in coding.

Acceptance Criteria

All files are scanned for linting issues on code push and/or PR
(Optional) Local linting is also configured for scanning prior to pushing to GitHub

Approach

Configure GitHub Actions to perform linting for all languages (Ruby, HTML, CSS, JS, etc.)

Notes

Question: Should linting happen on code push, PR, or...?
Question: Can we also setup local linting as part of the repo or does that require too much unique local setup?

Design and implement initial logo, tagline, branding, etc.

Background

Branding is important to any project for memorability and conveying the attitude of the product. Booze Hound should have a logo with the name, a possible mascot (separate from the logo), a tagline, and any other branding elements necessary.

Acceptance Criteria

A location within the repo has been identified for storing branding collateral (files) that will not be deployed with the product
A logo exists with the stylized product name
[Optional] A mascot exists that represents the attitude of the product
A tagline exists that reflects the usage of the product
Any other identified and necessary branding elements are created, such as:
- Small logo for favicon

Approach

[] Decide where in the repo to store collateral (source files, not rendered files for including within the application) to be excluded from deployments
[] Design drafts of the logo, mascot, tagline, and favicon
[] Review with Charles for approval of designs before final iterations are completed
[] Finalize designs and collateral (files)

Notes

Collateral (source files for branding) should be stored in the repository, but not in the deployable code directories at the following location:
- /path/to/be/determined/

Add follow/unfollow for stores

Background

Add the ability to follow stores and later unfollow them. For the moment, we will assume that the stores will be manually added by the administrator - i.e., we don't need to query all stores from OLCC (although that sounds like a cool feature for later).

Make it work like the bottles. "Stores you go to" would list the stores the followed stores. There would be a form box where you could enter a city name, and that would list all the stores we know about in that city. Then, you can start following new stores or unfollow from that list.

Acceptance Criteria

Buttons to follow/unfollow are shown in the store detail page
Daily update inventory job ignores inventory in stores that aren't followed
Add some unfollowed stores to the DB to show it's working
Specs for model/service doing this work, of course

Approach

It looks like I don't have a cached counter on stores the way I do for bottles - i.e., followers_count. Will need to add that and the functions on User to increment/decrement that.
Will want a Service object to orchestrate this change, just like bottles.
Add update to the stores controller
Add follow/unfollow forms to the show view for store

Notes

Once we have stores in the DB that aren't being followed, don’t update inventory for non-followed stores. (Maybe the system already does that.)

Select and configure vanity domain name and email addresses

Background

Once we decide on the official production name (maybe it's Booze Hound), we need to setup that domain and email for contacts, registering services, etc.

Acceptance Criteria

A vanity domain name is selected, purchased, and configured
Email addresses are configured as needed (email forwarding is fine)

Approach

Select a domain name
Purchase the domain name on Google Domains with free anonymous registration
Configure www and dev subdomains
Configure email addresses:
- info@, support@, etc.
- Email forwarding to our personal Gmail accounts is probably fine as we don't need full email accounts

Notes

Domain name ideas:

Booze Hound
LiquOregon
...others?

Create a helper function for user authentication check

Background

We need a way to check to see if the user is logged in to branch the UI between authenticated and anonymous content.

Acceptance Criteria

Prior to the real user authentication method being created, a helper function exists to check if the user is logged in and is available in the UI and returns a boolean for the logged-in status.
The function name and return type are documented here.

Notes

Enables #127

Enable Booze Hound v1.0 project in booze-hound repository

Background

To track the status of issues in the booze-hound repository, we need to setup a project. Kenny doesn't have access to setup a project in this repo, so Charles needs to do it or grant access to Kenny.

Acceptance Criteria

Charles has setup a project named Booze Hound v1.0 (or similar) or he has granted access to Kenny to setup the project
The project is then configured with the following settings:
- Type: board
- Project Name: Booze Hound v1.0
- Description: Project for tracking the initial release of Booze Hound (v1.0)
- Visibility: Private
- Manage Access: add Kenny and Charles as Admins
- States (the following are listed as label text color, description)
  - Pending, gray, This item isn't yet ready to be worked
  - Ready, pink, This item is ready to be worked
  - In Progress, orange, This is actively being worked on
  - In Review, green, This item is ready to be reviewed
  - Done, blue, This has been completed
Issues destined for v1.0 are added to the project

Approach

Determine if Kenny can be promoted to a role that allows for project creation or, if preferred, Charles can just create the project
Implement the configuration outlined above in the Acceptance Criteria
Add the issues for v1.0 to the project for tracking

Investigate missing index on olcc_bottles

Background

While working on #58 I discovered an issue with schema.rb. I'm showing a diff (locally) for the olcc_bottles table:

@@ -32,7 +32,6 @@ ActiveRecord::Schema[7.0].define(version: 2023_06_15_223946) do
     t.decimal "bottle_price"
     t.integer "followers_count", default: 0
     t.string "description"
-    t.index ["name"], name: "index_olcc_bottles_on_name"

(Kenny also saw this when we were setting up the Docker env.)

That line got added to schema.rb in e6bd4cd. I was doing some performance tweaking with indexes right before I took some time off. That commit adds 3 indexes in schema.rb but the migration only contains 2 of them. Why?

Acceptance Criteria

Determine if we need an index of bottle name
Create a migration to recreate the index, if needed.

Approach

Is the index in production or only dev? That would inform us about usefulness.

Notes

Price in the store inventory is poorly formatted

Background

Prices on the store inventory (maybe other pages) are not really currency-oriented, meaning they're lame:

It's trivial to add a $ before the number, and .0 isn't how we write amounts.

Acceptance Criteria

Fix this page.
Fix any other pages that display the price of a bottle

Approach

This seems like the sort of thing that Ruby/Rails might/should have a good built-in function for. For for something like that.

Notes

In-app user help documentation (help page)

Background

Users will need help documentation to assist in how to use Booze Hound. This is likely an issue to be resolved much later in the development lifecycle, but it should be considered throughout.

Acceptance Criteria

In-app help documentation for users exists and covers the necessary instructions for proper use
This documentation is available to end-users and is easily discovered, such as in a top-level navigation item

Approach

Write user help documentation (instructions) and include them in the app so users have easily discoverable documentation

Notes

Depending on how extensive the documentation is, we can just write it directly in HTML or we could write it in markdown and transform it into HTML.

Update Ruby version

Background

Update the version of Ruby to the latest 3.2.x version

Acceptance Criteria

App runs under latest version for both dev and prod

Approach

Start with the .ruby_version file
Update production Dockerfile
Update Dockerfile for development environment in #89

Notes

Add any additional notes go here, such as reference links.

Setup sitemap.xml and robots.txt

Background

To enable better search engine optimization, we need to have sitemap.xml and robots.txt configured.

Acceptance Criteria

sitemap.xml exists with correct data and is discoverable by search engines
robots.txt exists with correct configuration and is discoverable by search engines

Approach

See if we can automate the generation of sitemap.xml or, if it's too much work, just generate the basic static page URLs by hand (we may not need to map out every store, bottle, and distiller)
Determine what needs to go into robots.txt for proper scraping

Enable GitHub bot integration with Slack channel

Background

The owner of the repo has to enable toe GitHub Slack bot to allow for integration with a Slack channel.

Acceptance Criteria

The GitHub bot is enabled in the EchoNW #booze-hound channel for notifications

Approach

Charles runs /github subscribe cander/booze-hound in the #booze-hound Slack channel
The bot is configured for notifications on issues, PRS, deployments, etc.

Look into source data access

Background

Scraping the OLCC data from the website is doable, but risky as any changes would instantly break our app. We should see if it's feasible/possible to get access to the source data itself.

Acceptance Criteria

The feasibility of accessing the source data from OLCC is determined
A plan is made based on the results of the investigation of feasibility

Approach

Determine how we can CAREFULLY inquire about access to the source data from the OLCC
Figure out next steps based on the results of the inquiry