Add support for RESOLVE operations in safe_output.opal #37

Background

obiba/opalr#29 introduced a new RESOLVE operation in the DataSHIELD log. The operation indicates whether access to a table or resource could be resolved, including whether the resource exists and the user is authorised to access it. This will be included in Opal 6.0.

safe_output.opal() currently captures ASSIGN operations but does not capture RESOLVE operations. This means that some useful information about the resolution of DataSHIELD tables/resources is currently lost when constructing the audit RO-Crate.

Proposed change

Update safe_output.opal() to capture and parse both RESOLVE and ASSIGN operations.

The two operations provide complementary provenance information:

• RESOLVE → source asset resolution / provenance evidence
• ASSIGN → symbol creation / assignment evidence

In typical successful operations, a RESOLVE entry is followed by an ASSIGN entry. For example:

RESOLVE CNSIM.CNSIM1 → D
ASSIGN  D <- opal[CNSIM.CNSIM1]

However, this ordering should not be assumed to always occur. A RESOLVE operation may fail because the requested table/resource does not exist or the user is not authorised to access it. In that case, the corresponding server-side assignment may never occur.

Therefore, RESOLVE entries should be retained independently rather than being inferred solely from subsequent ASSIGN entries.

Provenance

The resulting audit trail should be able to represent the relationship between resource resolution, symbol assignment and subsequent analysis:

OPEN
  │
  ├── RESOLVE CNSIM.CNSIM1 → D
  │       │
  │       └── ASSIGN D <- opal[CNSIM.CNSIM1]
  │
  ├── PARSE dsBase::corDS(...)
  │
  └── AGGREGATE dsBase::corDS(...)

This allows the audit record to distinguish:

1. What source asset was resolved (RESOLVE)
2. What server-side symbol was created from that asset (ASSIGN)
3. What analysis subsequently used the symbol (PARSE / AGGREGATE)

Requirements

• Capture RESOLVE entries in safe_output.opal().

• Parse the relevant RESOLVE fields into the audit output.

• Continue capturing ASSIGN entries independently.

• Do not assume that every RESOLVE has a corresponding ASSIGN.

• Preserve sufficient information to associate a successful RESOLVE with its subsequent ASSIGN where both are present.

• Preserve failed/unsuccessful RESOLVE operations where they are present in the Opal log.

• Add/update tests covering:

  • successful RESOLVE followed by ASSIGN
  • RESOLVE without a subsequent ASSIGN
  • the resulting provenance relationships

Related

• feat: added RESOLVE operation field to indicate whether table/resource access was resolved (exists and authorized) obiba/opalr#29 - introduces the RESOLVE operation.
• This issue should ensure {dsROCrate} can preserve the new operation in audit RO-Crates before Opal 6.0 adoption.