Four cases covering the distinct grammar paths touched by the
new Key rule: dotted key in a TextPropertyRestrictionNode,
multi-level key (stressing the Kleene part), dotted key in a
GroupNode (the k:Key? branch), and a dot on the value side
that must stay a literal character.
Introduce a dedicated Key rule (Char+ ("." Char+)*) so property
restriction keys can contain dots. Queries like
audio.artist:Motörhead or photo.cameraMake:Apple now parse.
Goal: keep the data structure aligned with the query namespace.
A driveItem exposes nested fields as dotted paths in its API
response (photo.cameraMake, location.latitude); users should be
able to query with the same path, without admin-configured slot
mappings or alias tables like Microsoft requires.
Both bleve and OpenSearch already treat dots as the nesting
separator for field paths and pass unknown keys through
unchanged — only the KQL grammar blocked dotted keys via
Char <- [A-Za-z]. The new Key rule lifts that restriction; no
compiler changes or field-alias maintenance is needed.
Values are unaffected — dots in values still parse as literal
characters.
That can be helpful when the search service configuration has changed,
e.g. by enabling TIKA. Previously files that had already been indexed
were not indexed again and thus were no part of the fulltext index.
Fixes#2285Fixes#2578
This is to reduce the number of "proxy->gateway->users->ldap" roundtrips
for the tenant id mapping.
The cache currently has a non-configurable ttl of 10 min.
Related: #2310
When the tenant id coming in via the OIDC claims doesn't match the
tenant id on the provisioned user, a mapping can be configured and
resolved via the reva TenantAPI service (now started as part of the
"users" service).
Closes: #2310
Add UserExtraInfo (avatar + mail) to the WOPI CheckFileInfo response for
authenticated, non-public-share users.
UserExtraInfo format (per Collabora SDK):
https://sdk.collaboraonline.com/docs/advanced_integration.html#userextrainfo
```json
{
"avatar": "http://url/to/user/avatar",
"mail": "user@server.com"
}
```
After this change, CheckFileInfo returns:
```json
{
"BaseFileName": "Pedro-filled-hazcom.docx",
"UserFriendlyName": "Admin",
"UserId": "346364...39323030",
"UserCanWrite": true,
"UserCanRename": true,
"IsAdminUser": true,
"EnableInsertRemoteImage": true,
"EnableInsertRemoteFile": true,
"EnableOwnerTermination": true,
"UserExtraInfo": {
"avatar": "https://host:9300/wopi/avatars/{userID}?access_token={wopiToken}",
"mail": "admin@example.org"
},
"PostMessageOrigin": "https://localhost:9200",
"message": "CheckFileInfo: success"
}
```
Avatars are served via a new /wopi/avatars/{userID} endpoint on the
collaboration service, authenticated by the WOPI token. The endpoint
calls the Graph service directly (bypassing the proxy) using the reva
access token via x-access-token header.
All tests pass:
go test ./services/collaboration/... ./services/graph/... ./services/proxy/...
Signed-off-by: Pedro Pinto Silva <pedro.silva@collabora.com>
* adr: Add thoughts about guest users
The approach to take has not been decide yet. This just reflects
the current research/concept work.
* adr(guests): incorporate review feedback
* Mark ADR as postponed for now
We'd like to go for a more light-weight approach as discussed in:
https://github.com/opencloud-eu/opencloud/issues/2513
When multi-tenancy is enable we now allow to specify an OIDC claim
against which the tenantid of the user resolved via CS3 apis is matched.
Partial: #2310
Set EnableInsertRemoteFile: true in CheckFileInfo response so Collabora
shows "Insert Multimedia" and "Compare Document" menu entries. This
triggers UI_InsertFile postMessages to the WOPI host, following the same
pattern as the existing EnableInsertRemoteImage flag.
Signed-off-by: Pedro Pinto Silva <pedro.silva@collabora.com>
