Files
plane/apps/api
Manish Gupta 96c33544e6 fix(security): resolve the guard's permissions from get_permissions(), mirror partial_update on the other-surface scan
The class-level check read self.permission_classes directly, so a viewset
that restricts a mixin-served action only through a get_permissions()
override - without mutating the class attribute - would be invisible to the
guard and refused with a false 405. Nothing in the codebase requires an
override to mutate permission_classes as a side effect, so the guard now
calls self.get_permissions() and checks the effective, instantiated
permissions instead. get_permissions() is already invoked once earlier in
the same request via check_permissions(); calling it again here is the same
pattern DRF itself relies on and is safe given the one existing override in
this codebase has no side effects beyond reassigning permission_classes.

The other-surface (plane.api/plane.space) scan special-cased create's
perform_create delegation but had no equivalent for partial_update
delegating to an overridden update() - DRF's UpdateModelMixin.partial_update
calls self.update(), so that shape is actually authorized transitively, same
as the runtime guard already recognises. Added the matching exemption so the
scan does not misclassify it as an unguarded fall-through, and extracted the
per-route classification into _other_surface_route_is_unguarded() so it can
be exercised directly with synthetic viewsets instead of only through the
URL resolver.

The Copilot comment about _NON_AUTHORIZING_PERMISSIONS claiming both
permissions "establish identity" was already corrected in a prior commit on
this branch (e43770738f) - verified against current code, no further change
needed there.

Co-authored-by: Plane AI <noreply@plane.so>
2026-08-27 11:02:38 +05:30
..
2025-12-05 16:03:51 +05:30
2026-01-27 13:54:22 +05:30
2026-08-16 23:36:30 +05:30
2025-07-04 15:32:21 +05:30
2026-01-27 13:54:22 +05:30