update typo in store and user pages

[itsreverence]

No description provided.

[greptile-apps]

Greptile Summary

This PR fixes two fetch calls that were targeting /api/v1/users, a path that has no GET handler in UserController (only POST and DELETE are mapped there). Both pages were silently broken on load; the correction to /api/v1/users/admin — which is GET-mapped and restricted to the ADMIN role — makes them functional.

• stores.html: loadAdminUsers now correctly fetches from /api/v1/users/admin; the existing client-side role === \"ADMIN\" filter remains and is what actually scopes the list, since the endpoint returns all users.
• users.html: loadUsers now correctly fetches from /api/v1/users/admin, fixing a silent load failure on the user-management page.

Confidence Score: 4/5

Safe to merge — both pages were broken before this fix and the corrected endpoint exists and is properly secured.

The endpoint changes are correct and align with the UserController mappings. The only remaining concern is that stores.html fetches all users from an endpoint whose name implies admin-only output, then silently relies on a client-side role filter; if that filter drifts, the owner selector would show all users.

The client-side role === 'ADMIN' filter in stores.html (loadAdminUsers) deserves a second look to ensure the backend endpoint and client contract stay in sync over time.

Important Files Changed

Filename	Overview
src/main/resources/templates/stores.html	Corrects the fetch endpoint in loadAdminUsers from /api/v1/users (no GET mapping) to /api/v1/users/admin (GET-mapped, admin-secured). The existing client-side role === "ADMIN" filter over the full user list remains, which is redundant given the endpoint name but was pre-existing.
src/main/resources/templates/users.html	Corrects loadUsers to call /api/v1/users/admin instead of /api/v1/users. The old path had no GET handler defined in UserController, making the page silently fail on load.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant StoresPage as stores.html (loadAdminUsers)
    participant UsersPage as users.html (loadUsers)
    participant API as UserController (GET /api/v1/users/admin)

    Note over StoresPage,API: Before: GET /api/v1/users → no handler → 404/403
    Note over UsersPage,API: Before: GET /api/v1/users → no handler → 404/403

    Browser->>StoresPage: Open stores page
    StoresPage->>API: GET /api/v1/users/admin
    API-->>StoresPage: List of all UserDTOs
    StoresPage->>StoresPage: "filter(role === ADMIN)"
    StoresPage-->>Browser: Render admin user list

    Browser->>UsersPage: Open users page
    UsersPage->>API: GET /api/v1/users/admin
    API-->>UsersPage: List of all UserDTOs
    UsersPage-->>Browser: Render user management cards

Loading

Comments Outside Diff (1)

1. src/main/resources/templates/stores.html, line 1366-1368 (link)

   Redundant client-side filter after admin endpoint

   /api/v1/users/admin calls userService.getAllUsers() and returns every user in the database, not just admins. The role === "ADMIN" filter here is what actually scopes the list down. Callers of this function therefore silently depend on the client-side filter being correct — if it were ever removed or misspelled, the owner assignment UI would expose all users as selectable admins. Consider either renaming the backend endpoint to make its return scope clear, or adding a query parameter / dedicated endpoint that filters by role server-side so the contract is explicit.

_{Reviews (1): Last reviewed commit: "update typo in store and user pages" | Re-trigger Greptile}