Create a "comments" permission within Sonador to grant access to API in Orthanc

Summary

Adds comment_edit and comment_view ACL permissions to the Sonador authorization model and ensures they are correctly enforced by the Orthanc Advanced Authorization Plugin integration.

Background

The comment_edit and comment_view fields were added to the Sonador ACL model schema as part of the broader access control work in Milestone SN MS1. However, the permission enforcement logic in PacsImagingServerGroupAuthorization.user_has_perm was never updated to handle comment operations. As a result:

  • The permission fields existed in the data model and could be set via the API
  • But the enforcement logic checked modify for any POST/PUT/DELETE to a comment endpoint, blocking authorized users who had comment_edit: True but not modify: True
  • Writing functional tests for this issue revealed the bug

A secondary bug was discovered in the Orthanc Advanced Authorization Plugin: the plugin sends authorization checks at the patient, study, and series levels for resource requests, but at parent levels (patient, study) the uri field is empty. Without the URI, Sonador could not identify the operation as a comment action and fell back to generic permission checks.

Implementation

This issue required coordinated changes across four repositories. See the cross-repository summary comment below for the full dependency graph.

Sonador web application (oak-tree/medical-imaging/sonador!87)

  • Added comment_edit and comment_view as parsed properties on the authorization form
  • Updated user_has_perm to check comment_edit (for POST/PUT/DELETE) and comment_view (for GET) when action == 'comment'
  • Added local (Orthanc resource-level) ACL evaluation for CommentEdit and CommentView
  • Related issue: #75 (closed)

Orthanc Advanced Authorization Plugin (orthanc-authorization!1 (merged))

  • Added action: 'comment' field to resource authorization requests for all comment-related URLs (standard Orthanc API and DICOMweb, collection and item endpoints, all HTTP methods)
  • The field is propagated at all resource levels (patient, study, series) so Sonador has the context even when the URI is empty at parent levels
  • Requires IncludeResourceUri: true in plugin configuration
  • Related issue: orthanc-authorization#1 (closed)

Container build (orthanc-sonador!52 (merged))

  • Updated oaktreetech/sonador-orthanc base image to Ubuntu 26.04
  • Packaged the Sonador fork of the authorization plugin into the container build
  • Set IncludeResourceUri: true in the default plugin configuration

Functional tests (oak-tree/medical-imaging/sonador-client!70)

  • Added SonadorCommentPermissionTests — 15 test cases in sonador/ftests/tests_ext_comments.py
  • Covers global (Sonador server-level) and local (Orthanc resource-level) ACL enforcement
  • Covers standard Orthanc API and DICOMweb endpoints
  • Covers all four HTTP methods on comment resources

Behavioral Notes

  • comment_view: False at the global (Sonador) level does not gate reads when the user has view: True — comment read access is implicitly granted by resource view access. Granular CommentView enforcement requires a local (Orthanc resource-level) ACL.
  • Orthanc enforces comment authorship on PUT at the application level: only the comment creator can update text. This is an Orthanc constraint, not an ACL permission.
  • The Orthanc authorization plugin caches decisions by resource path. The test suite uses distinct user/group pairs per test to prevent cross-test contamination.

Test Specification

See comment from Sonador Claude for the full 15-test specification with per-test ACL setup and assertions.

Project Tracking

OP#138 OP#72

Edited by Sonador Claude