# Store Owner Audit — 2026-05-14 19:01:10 UTC

Running notes from the Store Owner accessible-pages audit. Bugs we
have already fixed are listed first for traceability; the open items
below are not yet patched and need a follow-up decision before merge.

## Fixed (commit b4defbe + this batch)

### Erratic table names (Hypervel surfaces these as empty 400s)
- `app/Http/Controllers/Market/ProductController.php:766`
  `pluck('stores.hashkey')` → `pluck('str.hashkey')`. Drove the
  Manage Listings modal in `ManageProductsAdmin.vue` to fail on every
  open.
- `app/Http/Controllers/Market/BatchController.php:91`
  `where('products.id', …)` → `where('prd_items.id', …)`. Broke the
  "already attached to this store" check in batch-import (existing
  mode).

### Validation/permission walls
- `ProductController::editProductAdmin` required `ModifyAllProducts`
  (Big-3 only) even when `data.store_hash` was supplied. STORE_OWNER
  edits via `UpdateProductModal.vue` returned 401. Now per-store
  edits only need `ModifyOwnProduct` / `AddProducttoOwnStore` plus
  the existing ownership branch.
- `ProductController::toggleProductStatus_Admin` — same gate, same
  relaxation.
- `ProductController::deleteProduct_Admin` required
  `DeleteAllProducts` (Big-3 only). Now accepts `DeleteOwnProduct`
  and the ancestor-of-creator path so owners can delete products
  they created.
- `PosController::voidSession` had no authorization check at all.
  Any session_hash could void any session. Now gated by
  `UserPermissions::isUserAllowedAccessToStore`.
- `PosAccessKeyController::destroy` and `toggleStatus` only checked
  the action permission. Now also verify the key belongs to a store
  the caller owns/manages.
- `StoreController::autoCreate` had no RBAC. Now requires
  Big-3 or STORE_OWNER, and dedupes generated names against the
  globally unique `str.name` index by appending a short suffix.
- `HomeStoreOwner.vue` referenced an undefined `creatingStore` ref
  (the actual ref is `creatingQuickStore`) — the "Creating your
  store..." spinner never rendered.

### BatchAddProducts opened to STORE_OWNER with guardrails
- `BatchController::batchCreateProducts` now allows STORE_OWNER, but
  only when `target_store_hash` is provided AND the target store is
  owned (or managed) by the caller. Without it the call is rejected
  up-front instead of silently 401-ing partway through the loop.
- New-mode rows are rejected when a global product with the same
  name (case-insensitive, trimmed) already exists. Owners are
  expected to pick the existing one via the fuzzy-search modal.
- `BatchAddProducts.vue` now redirects STORE_OWNER to CreateStore via
  a yes/no modal when they have zero selectable stores, and refuses
  submit if no target store is picked.

## Open — not yet patched, decide before merging

### `editStoreDetails` data leak (medium)
- File: `app/Http/Controllers/Market/StoreController.php:455`
- Route: `POST /Edit/Store/Details/data`
  (`routes/web.php:468-474`, middleware `auth + module:stores`).
- Behavior: looks up a `str` row by `hashkey`, and returns
  `name`, `category`, `subcategory`, `description`, `address`,
  `remarks`, `status`, `is_active`, `photourl`,
  `owner.hashkey`, `manager.hashkey`, all `store_managers` user
  hashkeys, all linked cooperative hashkeys, the parent-user
  selector list, and the dropzone payload — **without** any
  authorization check against the caller. Any authenticated user
  can issue this POST with any store's hashkey and get back the
  owner/manager/coop graph plus internal remarks. There is no
  modification path here, so this is information disclosure rather
  than escalation, but `remarks` is explicitly marked internal in
  the CreateStore flow and the manager/cooperative hashkeys leak
  the org graph.
- Suggested fix: require Big-3 OR
  (`store->owner_id`/`manager_id` matches caller)
  OR caller appears in `store_managers` pivot
  OR caller is ancestor of any of the above
  (the same predicate used by `canUserAccessPos` /
  `isUserAllowedAccessToStore`). Strip `remarks` from the response
  for non-Big-3.
- Status: **NOT FIXED IN THIS COMMIT.** Awaiting decision on
  whether to (a) tighten the endpoint and accept the chance of
  breaking any external/legacy caller, or (b) keep the
  read-anybody behavior and only strip `remarks`.

### Other observations (not bugs strictly)
- `editProductAdminByStore` (`ProductController.php:494`) has a
  `TODO Check first if store_id is owned by current user` comment
  and modifies the global product directly. Currently nothing
  routes to it, but leaving it in the codebase is a footgun if
  someone wires it up later. Recommend deleting.
- `listProducts_Admin` scopes non-Big-3 by `created_by`, so a
  store owner who attached a Big-3-created global product into
  their store cannot see/manage that product from "My Products".
  Per dictionary L265 this is intentional, but it does mean
  store-listings management for owners is split between
  "My Products" (creator-scoped) and the per-store flows
  (`AddProductsToStore`, `ManageStoresAdmin`).
- The Store Owner home's "Import Products" tile (`pagename:
  BatchAddProducts`) now works for STORE_OWNER thanks to the
  BatchController relaxation above. Pre-fix this would have
  loaded the page and then 401-ed on submit.

## Stores accessed during this audit
- `StoreController` (full file)
- `ProductController` (full file)
- `BatchController` (lines 33–172)
- `PosController` (sample around startSession/voidSession/getTodayStats)
- `PosAccessKeyController` (full file)
- Pages: `HomeStoreOwner.vue`, `CreateProductStoreOwner.vue`,
  `CreateStore.vue`, `AddProductsToStore.vue`, `BatchAddProducts.vue`,
  `ManageProductAdmin.vue`, `ManageProductsAdmin.vue`,
  `ManageStoresAdmin.vue`, `PosAccessKeys.vue`,
  `UpdateProductModal.vue`
- Routes: `routes/web.php` (home-data + Store/Product/POS blocks)