// Where a given account's notification screens live.
//
// **Staff and players reach the same two screens at different paths, and that is
// this file's whole reason to exist.** `/auth/me/notifications` is role-agnostic
// — behind `requireAuth` only, like every other `/auth/me` route — but the WEB
// has two logged-in shells: `RequirePlayer` sends anyone who is not a player to
// the admin area, where staff manage their own account under `/admin/account`.
// So a bell that always pointed at `/account/notifications` would, for every
// staff member, point at a page that redirects.
//
// Discovered in the Phase 7 rig: signed in as an admin, the inbox was simply
// unreachable on the web. Two routes, one pair of components, one mapping here.

export const isStaff = (user) => !!(user && user.role && user.role !== 'player')

/** The inbox — what the bell opens. */
export const inboxPath = (user) => (isStaff(user) ? '/admin/notifications' : '/account/notifications')

/** The per-channel preferences screen. */
export const notificationSettingsPath = (user) =>
  isStaff(user) ? '/admin/notifications/settings' : '/account/notifications/settings'

/**
 * This account's own event participation (events Phase 14a).
 *
 * The third screen to need this mapping, and it needed it for exactly the reason
 * the two above did: `GET /player/events/history` is behind `requireAuth` alone,
 * self-scoped on `req.user.id` — a staff member has a participation history like
 * anyone else, and the group's own header says staff are a superset of players.
 * The WEB is what disagrees, because `RequirePlayer` sends them to the login
 * page. Found the same way the notifications pair was: signed in as an admin,
 * the screen simply redirected.
 */
export const eventHistoryPath = (user) =>
  isStaff(user) ? '/admin/events/mine' : '/account/events'