Skip to content

Declare report-instance as child resource of report-definition - #1213

Open
DarshitChanpura wants to merge 1 commit into
opensearch-project:mainfrom
DarshitChanpura:fix/report-instance-parent-sharing
Open

Declare report-instance as child resource of report-definition#1213
DarshitChanpura wants to merge 1 commit into
opensearch-project:mainfrom
DarshitChanpura:fix/report-instance-parent-sharing

Conversation

@DarshitChanpura

@DarshitChanpura DarshitChanpura commented Aug 6, 2026

Copy link
Copy Markdown
Member

Description

Declares parentType/parentIdField on the report-instance resource provider so report instances inherit access from the report definition they were generated from — whoever can access a definition can access its generated reports. The parent id is extracted from the flattened reportDefinitionDetails.id field, already indexed as keyword in report-instances-mapping.yml.

Why this is needed:

  • Scheduled report instances are indexed by jobs running under job-scheduler with no authenticated user in the thread context; the security plugin cannot attribute a sharing entry to them. With this change + Create parent-linked sharing entries for child resources written without a user security#6373, those instances receive parent-linked entries inheriting the definition owner's access.
  • Semantics: instances have no independent access model — they are outputs of their definition. Child declaration makes evaluation delegate to the definition's shares natively.

Context: the resource-sharing onboarding (#1141, 2025-12-10) predates parent/child support in the SPI (security#5735, 2026-03-23), so this wiring could not be added at onboarding time and was never retrofitted.

Investigation note (correction)

An earlier version of this description claimed on-demand instances are indexed under the plugin subject and receive no sharing entries. That was traced to listener-attachment timing on a 3.8.0 snapshot instead (type added to protected_types dynamically after the instances index was already open — no listener until restart). On-demand writes do carry the user and receive entries once the listener is attached; the child declaration remains necessary for scheduled instances and for correct inheritance semantics.

Depends on

opensearch-project/security#6373 (parent-linked entries for user-less writes; integration-tested there)

Category

Bug fix

Testing

  • compileKotlin passes; field name verified against the index mapping
  • Child→parent inheritance semantics covered by security#6373 integration tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Report instances never received resource-sharing records: the on-demand
creation path indexes the instance doc under the plugin subject (via
PluginClient) and scheduled runs execute under job-scheduler, so the
security plugin's ResourceIndexListener finds no authenticated user and
silently skips record creation. As a result instances are invisible to
the resource-sharing APIs, even to their creator.

Declaring parentType/parentIdField on the report-instance provider makes
instances inherit access from the report definition they were generated
from, which matches the intended semantics: whoever can access a
definition can access its generated reports. The parent id is extracted
from the flattened reportDefinitionDetails.id field, which is already
indexed as keyword in report-instances-mapping.yml.

Requires the companion security plugin change that creates parent-linked
records when no user is present in the thread context.

Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
@github-actions

Copy link
Copy Markdown
Contributor

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ No major issues detected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants