docs(halopsa): correct OAuth scopes and login type

[lc-cbot]

Summary

Two corrections to the HaloPSA extension setup instructions in docs/5-integrations/extensions/third-party/halopsa.md, verified against a live HaloPSA tenant.

1. OAuth scopes

The previous list claimed read:tickets edit:tickets read:customers edit:customers read:assets edit:assets read:actions edit:actions. Findings:

• read:actions and edit:actions do not exist — HaloPSA's /auth/token endpoint rejects them as invalid_scope. Actions are a sub-resource of Tickets and are gated by :tickets scopes.
• read:tickets is redundant when edit:tickets is granted (verified by probe).
• read:assets is redundant when edit:assets is granted.
• edit:customers is unneeded because ext-halopsa only does read-only client/site lookups (sites are gated by :customers too — there is no :sites scope).

Verified minimum: edit:tickets edit:assets read:customers.

2. Login Type

The previous instruction said "Log on as the Application (the API acts as itself, not as a specific agent)." HaloPSA does not have an "Application" login type — the field's options attribute API requests to a specific agent, which is visible in the id_token JWT returned by /auth/token (it includes name, email, and HaloPSA agent id). Corrected to instruct picking the owning agent.

How this was verified

Probed every scope individually against the live HaloPSA tenant, then ran the verified minimum end-to-end against every endpoint the extension uses:

Action	Endpoint	Result with minimum scope
create_ticket	POST /api/Tickets	201
update_ticket	POST /api/Tickets (with id)	201
search_tickets	GET /api/Tickets	200
add_action	POST /api/Actions	201
link_asset_to_ticket	GET /api/Asset, POST /api/Asset, GET /api/Tickets/{id}, POST /api/Tickets	all 200/201
lookup_client_site	GET /api/Client, GET /api/Site	200

Additional findings worth knowing for future docs work:

• HaloPSA has no actions scope domain — Actions are gated by :tickets.
• HaloPSA has no sites scope domain — Sites are gated by :customers.
• HaloPSA's permission enforcement is non-uniform: read:tickets is enough to create a ticket via POST /api/Tickets (returns 201) but is rejected on update with 400 "You do not have permission to update this Ticket". Same pattern with read:assets. We still recommend edit:tickets / edit:assets for clarity and to cover the update paths.
• HaloPSA returns HTTP 500 (not 403) when hitting /api/Actions with the wrong scope domain. Worth knowing when triaging.

Six test records (3 tickets, 3 assets, tagged [ext-halopsa scope probe]) were created during verification and cleaned up with DELETE calls afterwards.

A matching update has been made to the README.md and the scope field's PlaceHolder in the ext-halopsa repo (separate change).

Test plan

• Doc renders cleanly in the docs site.
• Spot-check that the new permissions list and Login Type instruction are consistent with the rest of the page.

🤖 Generated with Claude Code