Skip to content

feat: add search query endpoint with request examples#34

Open
dschmidt wants to merge 4 commits intomainfrom
feat/search
Open

feat: add search query endpoint with request examples#34
dschmidt wants to merge 4 commits intomainfrom
feat/search

Conversation

@dschmidt
Copy link
Copy Markdown
Contributor

@dschmidt dschmidt commented Apr 10, 2026

Added a new search endpoint for querying resources with detailed request and response structures, including examples for various search scenarios.

Based on the MS Graph Search Api of course:

https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview?view=graph-rest-1.0

I'm also willing to implement that endpoint

Added a new search endpoint for querying resources with detailed request and response structures, including examples for various search scenarios.

Based on the MS Graph Search Api of course: 

https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview?view=graph-rest-1.0
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an OpenAPI definition for a new beta search endpoint modeled after Microsoft Graph Search, including request/response schemas and multiple example payloads to document common search scenarios.

Changes:

  • Introduces POST /v1beta1/search/query with detailed description and request/response examples.
  • Adds search-related schemas (searchRequest, searchQuery, searchResponse, aggregation/bucket schemas) under components/schemas.
  • Wires the new endpoint to the new schemas via $ref to keep the spec structured.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread api/openapi-spec/v1.0.yaml
Comment thread api/openapi-spec/v1.0.yaml
Comment thread api/openapi-spec/v1.0.yaml
Comment thread api/openapi-spec/v1.0.yaml Outdated
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread api/openapi-spec/v1.0.yaml Outdated
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@aduffeck
Copy link
Copy Markdown
Member

@dschmidt Since the search endpoint returns plain drive items I'm wondering how we would handle the additional information the results are currently being enriched with (see https://github.com/opencloud-eu/opencloud/blob/main/services/webdav/pkg/service/v0/search.go#L150-L263 for the current state).

Things like the tags could be derived from the arbitrary metadata (which currently isn't exposed afaict), but do you have an idea how we would handle the oc:has-preview (depends on a server-side list of supported mimetypes) and oc:favorite (depends on the user running the search and the favorites metadata which is not part of the arbitrary metadata) flags.

@dschmidt
Copy link
Copy Markdown
Contributor Author

Very good questions, thanks!

I assume hasPreview could be expressed using the thumbnails relationship: https://learn.microsoft.com/en-us/graph/api/driveitem-list-thumbnails?view=graph-rest-1.0&tabs=http

favorite is trickier, as it's a user specific value and usually driveItems and all their data are not bound to a user.
Afaict MS Graph has nothing like that - the closest as a concept might be "following", c.f. https://learn.microsoft.com/en-us/graph/api/drive-list-following?view=graph-rest-1.0&tabs=http
But that does not seem to have a prop on the item. Which is very unhandy to work with.

Although this introduces user specific data to the driveItem, We could introduce a custom prop like @libre.graph.favorite or similar.
Maybe even @libre.graph.user.favorite to make it obvious it's user specific.

@dschmidt
Copy link
Copy Markdown
Contributor Author

The thumbnails relationship is already in the spec, it might still need implementation tho 😅

@dschmidt
Copy link
Copy Markdown
Contributor Author

dschmidt commented Apr 14, 2026

Aha, I just realized the follow endpoints map to setting the favorite state... so just @libre.graph.following or @libre.graph.user.following on the driveItem?

If you agree, I can send another PR for that, to keep this one scoped

@dschmidt
Copy link
Copy Markdown
Contributor Author

#37 👀

@dschmidt
Copy link
Copy Markdown
Contributor Author

What's also potentially missing: short permissions/allowed actions without loading all shares

Not sure how we want to do that? Thoughts?

@butonic
Copy link
Copy Markdown
Member

butonic commented Apr 21, 2026

What's also potentially missing: short permissions/allowed actions without loading all shares

Not sure how we want to do that? Thoughts?

we introduced @libre.graph.permissions.roles.allowedValues and @libre.graph.permissions.actions.allowedValues to let the web ui build the sharing dialog.

see https://docs.opencloud.eu/docs/dev/server/apis/http/graph/permissions for what that looks like or just monitor your browsers network tab when opening the sharing dialog in the web ui.

Let me know if that covers what you have in mind

dschmidt added a commit that referenced this pull request Apr 21, 2026
Adds an optional, `$select`-gated instance annotation on `driveItem` that
carries the list of libre.graph actions the caller is allowed to perform on
the item. Mirrors the annotation of the same name on the `/permissions`
endpoint so clients (e.g. a sharing dialog in a search/listing UI) can get
the effective-actions view inline without a separate round-trip per item.

- Adds `@libre.graph.permissions.actions.allowedValues` to the `driveItem`
  schema, marked read-only and documented as only populated when requested.
- Adds a reusable `driveItemSelect` component parameter with a narrow enum,
  following the same pattern as PR #38 (feat/download-url). When both land,
  the enum values merge.
- Wires the new parameter to `GetDriveItem`.

Rationale discussed in #34.
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.

4 participants