Limit a QuerySet by CBAC (Shared ontology for object claims)

[japsu]

For example, the following use cases would need to limit objects by CBAC:

https://github.com/orgs/con2/projects/3/views/1?filterQuery=&pane=issue&itemId=46277628

In order for this to work, we need to define a shared ontology for object based access via CBAC.

For example, when a survey owner wants to see responses of a query, the claims tested by graphql_query_cbac_required are currently field oriented:

organization=tracon-ry
event=hitpoint2024
app=forms
view=graphql
operation=query
object_type=EventSurvey
slug=larp-survey
field=resolve_responses

And when a survey owner wants to download those same responses, this is used instead:

organization=tracon-ry
event=hitpoint2024
app=forms # FIXME missing (should be added)
view=forms_event_survey_excel_export_view
method=GET
path=/events/hitpoint2024/surveys/larp-survey/responses.xlsx

My initial thoughts on this are, that we should be able to differentiate at least the following actions:

• see the responses (either all or one) of a survey
• download the responses as excel of a survey
• delete a survey response

These suggest we should have at least organization, event, app=forms, survey (the latter being the slug of the survey) as claims to identify a survey, all surveys of an event, or all event surveys of an organization.

Furthermore, we need to differentiate see responses, download responses and delete survey response as some kind of action. (Name of the action claim? action, operation? Spelling of its values?

Likely we cannot tie these to RESTonomics, but neither can we tie them to GraphQLinquistics.

When we have such a shared ontology, then we can construct a limit_queryset that could look something like

qs = limit_queryset(self.responses.all(), request.user, action="download responses")

that should introspect as many claims as can be introspecten and accept further claims as kwargs, ending up in a list of claims such as

organization=tracon-ry
event=hitpoint2024
app=forms
type=EventSurveyResponse # object_type/kind/model? is it better to identify by the parent or the list item type?
survey=larp-survey
action=download responses