4 Commits

Include renames

Author	SHA1	Message	Date
jaredandClaude Sonnet 5	6609320c83	Restrict API keys to public-visibility tickets by default (#70) ... api/tickets_api.php (both the single-ticket read and the list/triage path) bypassed ticket visibility entirely for any 'read'-scope key, regardless of who it was issued to or what it was for — any key got blanket read access to Confidential and Internal ticket titles, descriptions, and comments, with no way to scope a key more narrowly. Added see_all_visibility to api_keys (migration 006), defaulting to false for both new and existing keys — the prior blanket-access behavior is what's being restricted here, so unlike scope's own un-migrated-database fallback (which defaults toward preserving old behavior), a missing/null value here defaults to the new, restrictive one. An admin can opt a specific key in via a new checkbox in the API Key Management UI when it genuinely needs the full queue. tickets_api.php now builds a synthetic "no special access" user and runs it through TicketModel's existing per-user visibility plumbing (getVisibilityFilter/canUserAccessTicket) instead of a separate SQL path, so this stays in lockstep with however visibility rules evolve for real users. That synthetic user_id is -1, not 0: testing surfaced that canUserAccessTicket()'s confidential-ticket check does a PHP-level (int) cast, and (int)null === 0, so an unassigned confidential ticket's NULL assigned_to would otherwise false-positive-match a user_id of 0. Verified against real MariaDB with public/confidential/internal test tickets: a public-only-scoped key's list only returns the public ticket, and canUserAccessTicket() correctly returns false for both the confidential ticket (unassigned, then reassigned to a real user — both cases) and the internal one; a see_all_visibility key sees all three, unchanged from the prior behavior. Also verified createKey()/ validateKey()'s default-false and explicit-true paths round-trip correctly through the real DB. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117oBw2jN4kALYeS8HPq4zV	2026-09-12 01:17:53 -04:00
jaredandClaude Opus 4.8	5cf5aa9591	API keys: add read/read_write scopes + admin scope selector & pagination ... Foundation for extending the Bearer API beyond create-only: - api_keys gains a scope column (read | read_write); baseline schema updated and the column applied to the live DB. Existing keys default to read_write so the hwmon create key keeps working. - ApiKeyModel: createKey() takes a validated scope; validateKey() always surfaces scope (defaults read_write); getAllKeys() is paginated ({keys,total,page,perPage}, key_hash stripped). - ApiKeyAuth: expose getKeyContext() (scope/key_name/created_by/api_key_id) and requireScope() (403 on insufficient scope); existing return values unchanged. - create_ticket_api.php: require read_write scope (a read key can't create). - Admin /admin/api-keys: scope selector on the create form, a scope column, and pagination (revoked keys were stacking up). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 18:24:50 -04:00
jared	c90bdc8ac8	style: auto-fix 1340 phpcs PSR-12 violations via phpcbf; exclude MissingNamespace and SideEffects	2026-04-13 20:56:10 -04:00
jared	7b25ec1dd1	SSO Update :)	2026-01-01 15:40:32 -05:00