feat: Add @libre.graph.user.following and @libre.graph.tags properties to driveItem

[dschmidt]

Summary

Add two read-only properties to the driveItem schema:

• @libre.graph.user.following (boolean) — whether the current user is following this item
• @libre.graph.tags (string array) — the tags assigned to this item

Motivation

The OpenCloud web frontend currently uses WebDAV REPORT for search. The REPORT response includes oc:favorite and oc:tags per result. To replace WebDAV search with the Graph Search API, the driveItem resource must carry the same information — otherwise the Graph search is not equivalent and cannot fully replace REPORT.

Both properties already have dedicated mutation endpoints:

• Following: POST .../items/{id}/follow / DELETE .../following/{id}
• Tags: PUT /extensions/org.libregraph/tags / DELETE /extensions/org.libregraph/tags

But the driveItem resource itself does not expose the resulting state. This PR closes that read gap.

Changes

Two new properties on the driveItem schema:

'@libre.graph.user.following':
  description: |
    Indicates whether the current user is following this DriveItem. Read-only.
    Use the FollowDriveItem and UnfollowDriveItem operations to change the following state.
  type: boolean
  readOnly: true
'@libre.graph.tags':
  description: |
    The list of tags assigned to this DriveItem. Read-only.
    Use the AssignTags and UnassignTags operations to modify tags.
  type: array
  items:
    type: string
  readOnly: true

Both are readOnly because dedicated mutation endpoints already exist.

Design considerations

Naming

Both properties use the @libre.graph.* prefix as they are OpenCloud-specific extensions not present in the MS Graph API.

@libre.graph.user.following additionally uses a user segment to indicate it is user-specific — different users see different values for the same DriveItem. This is the first property using this prefix pattern and establishes a convention for potential future user-specific properties.

@libre.graph.tags has no user segment because tags are global — all users see the same tags on an item.

Why read-only

Both properties reflect state that is managed through dedicated endpoints:

Property	Read	Mutate
@libre.graph.user.following	on driveItem (this PR)	FollowDriveItem / UnfollowDriveItem
@libre.graph.tags	on driveItem (this PR)	AssignTags / UnassignTags

Making them writable on the DriveItem would introduce a second mutation path for the same state, which complicates the API and raises questions about event semantics (should a PATCH that changes tags emit a TagsAdded event?). Keeping them read-only avoids this.

Implementation notes

Both properties are already available in the backend — no storage or index changes needed:

Following: The favorite state is stored as a per-user xattr (user.oc.fav.{userId}) and read via ArbitraryMetadata (key http://owncloud.org/ns/favorite). The FollowDriveItem handler already calls Stat and builds a driveItem response — it just doesn't populate the following field yet. In cs3ResourceToDriveItem(), the implementation needs to check the ArbitraryMetadata for the favorite key and set the property.

Tags: Tags are stored in ArbitraryMetadata (key tags, comma-separated string) and indexed in the Bleve search index as a string array. The WebDAV search response already reads and returns them. The Graph service needs to do the same in cs3ResourceToDriveItem() by reading ArbitraryMetadata["tags"] and splitting it into the string array.

WebDAV REPORT parity

With these two properties, the gap between WebDAV REPORT and the Graph API narrows to only search-specific fields that belong on a future searchHit resource, not on driveItem:

WebDAV Property	driveItem equivalent	Status
oc:favorite	@libre.graph.user.following	this PR
oc:tags	@libre.graph.tags	this PR
oc:highlights	→ future searchHit.summary	search-specific
oc:score	→ future searchHit.rank	search-specific
oc:has-preview	→ thumbnails	spec available, impl. missing