hasPermission()'s parameter was named userRole: string, shadowing the module-level userRole role object exported earlier in the same file. The internal roles map's `user: userRole` entry therefore bound to the shadowed string parameter (e.g. "user") instead of the actual role object — so any permission check for a "user"-role session (the only non-admin role in the app) hit `"user".statements[resource]`, which is undefined, and threw instead of returning false. Net effect: every requirePermission()-gated route in the app returned a 500 instead of a 403 for non-admin users. This predates phase 14 — surfaced now because phase 14's PAX8 resolve route is admin-gated and got exercised by a non-admin account during verification. Renamed the parameter to roleName to remove the collision. Added lib/permissions.test.ts (previously zero coverage on this file) to lock in the "user"/admin/super-admin behavior and prevent regression.
25 lines
941 B
TypeScript
25 lines
941 B
TypeScript
import { describe, it, expect } from 'vitest';
|
|
import { hasPermission } from './permissions';
|
|
|
|
describe('hasPermission', () => {
|
|
it('returns false (not a crash) for a "user" role on an admin-only resource', () => {
|
|
expect(() => hasPermission('user', 'admin', 'access')).not.toThrow();
|
|
expect(hasPermission('user', 'admin', 'access')).toBe(false);
|
|
});
|
|
|
|
it('returns true for "admin" role on an admin-gated resource', () => {
|
|
expect(hasPermission('admin', 'admin', 'access')).toBe(true);
|
|
});
|
|
|
|
it('returns true for "super-admin" role on an admin-gated resource', () => {
|
|
expect(hasPermission('super-admin', 'admin', 'access')).toBe(true);
|
|
});
|
|
|
|
it('returns true for "user" role on a permitted resource', () => {
|
|
expect(hasPermission('user', 'tickets', 'read')).toBe(true);
|
|
});
|
|
|
|
it('returns false for an unknown role', () => {
|
|
expect(hasPermission('bogus-role', 'admin', 'access')).toBe(false);
|
|
});
|
|
});
|