mirror of
https://github.com/makeplane/plane.git
synced 2026-09-01 19:48:42 +02:00
e43770738f
Review caught a real divergence. The runtime guard treats
`{IsAuthenticated, AllowAny}` as non-authorizing, but the scan covering
plane.api and plane.space restated the rule as "not (IsAuthenticated,) and not
()". That silently accepted `[AllowAny]` as a deliberate restrictive
declaration, so a viewset there declaring AllowAny and falling through to a DRF
mixin would never appear in the manifest — on plane.space, the one surface where
AllowAny is routine (10+ classes use it today, all APIViews rather than
viewsets, so nothing is currently masked). The two tests also directly
contradicted each other: one asserts that shape is unauthorized while the other
skipped it.
The scan now imports `_NON_AUTHORIZING_PERMISSIONS` from the guard instead of
restating it, so the two cannot drift apart again. This is the same mistake the
guard itself had before review — "differs from the default" is not the same
question as "actually authorizes" — and restating a rule in a second place is
what let it survive in one of them.
Also: correct the comment on that set, which claimed both classes "establish
identity" when AllowAny does not; make initial()'s comment precise about what
ordering after super() actually buys (the permission classes' own rejection and
status code win, rather than a 405 disclosing that the route exists); and use
`pass` rather than a bare ellipsis for the test stub bodies.
Co-authored-by: Plane AI <noreply@plane.so>