Relates to: SZ-76 (Support for guests and community/customer users)

Summary

Implement server-side enforcement of permissions based on user_type, restricting external users (CUSTOMER, PARTNER, GUEST, COMMUNITY) to a defined set of read and limited write operations across the REST API.

Builds on the user_type field, comment visibility controls, and watermark UI delivered in 1.9.x. This issue closes the gap where an external user with a valid account could currently perform any operation an internal team member can.

Background

The users table already carries a user_type column (INTERNAL, CUSTOMER, PARTNER, GUEST, COMMUNITY) introduced in V06. Comment visibility is already filtered server-side based on this value. However, no other API endpoints currently check user_type, meaning an external user can create issues, merge pull requests, and delete repositories.

Permitted operations for external users

Implementation

New component: ExternalUserPolicy

A single Spring @Component that is the sole enforcement point across all controllers. No inline user_type checks scattered through business logic.

com.sztab.policy.ExternalUserPolicy
  + resolveType(Authentication) : UserType
  + isExternal(Authentication)  : boolean
  + requireInternal(Authentication) : void  // throws AccessDeniedException -> 403

IssueUpdateDto

Add an overloaded applyTo(Issue, UserType) method. For external callers only the priority field is applied; all other fields in the request body are silently ignored. Internal callers delegate to the existing applyTo(Issue) — no behaviour change.

Controllers updated

IssueController

• POST /api/issues — blocked for external users
• GET /api/issues, GET /api/issues/{id}, GET /api/issues/by-key/{key} — allowed, requesterType threaded through to IssueDto.fromEntity (fixes comment visibility drift introduced since the original implementation)
• PATCH /api/issues/{id} — allowed, but delegates to priority-only applyTo overload
• DELETE /api/issues/{id} — blocked for external users
• GET /api/issues/{id}/comments — allowed, requesterType applied
• POST /api/issues/{id}/comments — allowed (visibility enforcement already in place)

PullRequestController

• POST /api/pullrequests — blocked
• PUT /api/pullrequests/{id} — blocked
• POST /api/pullrequests/{id}/merge — blocked
• POST /api/pullrequests/{prId}/reviews — blocked
• PUT /api/pullrequests/{prId}/comments/{commentId} — blocked
• All GET endpoints — allowed unchanged

GitRepoController

• POST /api/repos — blocked
• DELETE /api/repos/{id} — blocked
• All GET endpoints — allowed unchanged

Out of scope

The following are tracked separately under the GitHub-style authorisation design issue:

• Project-scoped roles (OWNER, MAINTAINER, DEVELOPER, REVIEWER, REPORTER, GUEST)
• Branch protection rules
• Git layer enforcement (Sztabina pre-receive hook)
• Anonymous / public project access

Acceptance criteria

• An external user receives 403 Forbidden on any blocked endpoint regardless of other role assignments
• An external user PATCH /api/issues/{id} with a body containing severity, status, and priority — only priority is applied; severity and status unchanged
• Internal users are completely unaffected
• Comment visibility filtering is consistent across all issue GET endpoints
• No user_type checks exist outside ExternalUserPolicy

Time estimate