* test:start auth-bearer service separately instead of via OCIS_ADD_RUN_SERVICES
* test: fix timezone-dependent expiry assertions and flaky email notification
* test: simplify host timezone detection and log the UTC fallback
* test: oonly run cli commands test suite
* test: run all suites
* test: resolve the expiry timestamp in the timezone the mail was sent in
* test: inline the UTC expiration date conversion and drop the helper
* test: simplify the mail timezone formatter and restore the CI coverage guard
* test: rollback sending last chunk twice status code to only 404
* test: run all suites
* test: run coreApiWebdav remaining suite in k8s
* test: exclude coreApiWebdavPreviews
* feat(collaboration): add Version to Collabora WOPI CheckFileInfo
Add Version field to the Collabora struct to match Microsoft and OnlyOffice
implementations. This allows Collabora Online to properly detect stale
documents for cache invalidation and document reload detection, which is
particularly important in multi-node Kubernetes deployments.
- Add Version field to Collabora struct with json:"Version,omitempty" tag
- Add case for KeyVersion in Collabora.SetProperties method
- Update existing Collabora integration tests to verify Version is populated
- Add three unit tests for Version handling in collabora_test.go
- Add integration test verifying Collabora CheckFileInfo response includes Version
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add LastModifiedTime to Collabora CheckFileInfo for conflict detection
Add LastModifiedTime to the Collabora struct to match Microsoft and OnlyOffice,
and implement the X-COOL-WOPI-Timestamp conflict detection PutFile relies on to
use it. Collabora Online tracks the LastModifiedTime it received in
CheckFileInfo and sends it back during PutFile; without this field the WOPI
host has no way to detect that a file changed since Collabora last checked it,
so concurrent edits could silently overwrite each other.
- Add LastModifiedTime field to Collabora struct (json:"LastModifiedTime,omitempty")
and wire it in Collabora.SetProperties via the existing KeyLastModifiedTime constant
- fileconnector.go already populates KeyLastModifiedTime unconditionally for all
targets, so no gating changes were needed there
- Add HeaderCoolWopiTimestamp ("X-COOL-WOPI-Timestamp") constant and thread it
from HttpAdapter.PutFile through the ContentConnectorService.PutFile interface
- ContentConnector.PutFile compares the client-supplied timestamp against the
file's current mtime and returns a new NewResponseCOOLConflict() (409,
COOLStatusCode 1010) on mismatch; an empty timestamp (Microsoft/OnlyOffice,
and file-creation call sites in PutRelativeFileSuggested/Relative) skips the
check entirely, so existing WOPI clients see no behavior change
- Hand-updated the mockery-generated ContentConnectorService mock (mockery
itself fails to build under the local Go toolchain) and every PutFile call
site/mock expectation across fileconnector.go, fileconnector_test.go,
contentconnector_test.go and httpadapter_test.go for the new 5-arg signature
- Add fileinfo/collabora_test.go unit tests for LastModifiedTime SetProperties/
JSON marshalling/omitempty, update the 3 existing Collabora CheckFileInfo
integration tests with the expected LastModifiedTime, and add PutFile tests
covering COOL timestamp mismatch (409) and match (success) in
contentconnector_test.go
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(collaboration): handle nil Mtime and add HttpAdapter test coverage for COOL WOPI timestamp
The COOL conflict-detection check in ContentConnector.PutFile treated a
nil Mtime as an automatic mismatch, causing a permanent 409 on every
save for files with no recorded mtime. Skip the comparison (fail open)
when Mtime is nil, matching CheckFileInfo's fallback posture. Also add
a regression test for that case, plus a test asserting HttpAdapter.PutFile
correctly reads the X-COOL-WOPI-Timestamp header and passes it through
to the content connector, which previously had no coverage.
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add ReadOnly to Collabora WOPI CheckFileInfo
Add ReadOnly to the Collabora struct to match Microsoft and OnlyOffice, and
populate it in CheckFileInfo for all three targets. KeyReadOnly already
existed as a constant and both Microsoft.SetProperties and
OnlyOffice.SetProperties already had a `case KeyReadOnly:`, but nothing in
fileconnector.go ever put a value into the properties map for it - so
ReadOnly was silently false for every WOPI target, regardless of whether the
user actually had write access.
- Add ReadOnly field to the Collabora struct (json:"ReadOnly", no omitempty,
consistent with Microsoft/OnlyOffice since false is meaningful) and wire it
in Collabora.SetProperties via the existing KeyReadOnly constant
- In fileconnector.go's CheckFileInfo, set
infoMap[fileinfo.KeyReadOnly] = wopiContext.ViewMode != VIEW_MODE_READ_WRITE
unconditionally for all targets. wopiContext.ViewMode is already resolved
upstream from the actual CS3 permissions, space status and lock state, so
this derives ReadOnly from that single source of truth instead of
re-deriving the same signals in the connector
- Add fileinfo/collabora_test.go unit tests for ReadOnly SetProperties (true/
false) and JSON marshalling (asserting the field is present for both true
and false, since there is no omitempty)
- Add two new CheckFileInfo integration tests asserting ReadOnly=true for a
view-only mode and ReadOnly=false for read-write, and add ReadOnly: true to
the 4 existing CheckFileInfo integration tests that assert a full
Microsoft/Collabora/OnlyOffice struct under a non-read-write ViewMode
(the 2 ViewMode assignments in the Lock/GetLock test block were left
untouched since those tests don't assert against a FileInfo struct)
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add SupportsUpdate to Collabora WOPI CheckFileInfo
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(collaboration): add missing godoc comment to Collabora.SupportsUpdate
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add IsAnonymousUser to Collabora WOPI CheckFileInfo
Implement support for the IsAnonymousUser property in the Collabora struct,
enabling Collabora Online to distinguish between authenticated and anonymous
users (public share access). This property is derived from the user context's
public-share-role indicator and is already computed in fileconnector.go.
Changes:
- Add IsAnonymousUser field to Collabora struct with omitempty tag
- Wire KeyIsAnonymousUser case in SetProperties
- Add unit tests: SetProperties behavior, JSON omit/include when false/true
- Add integration tests: anonymous user context returns true, authenticated
user returns false, UserId still populated for anonymous users
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add URL properties to Collabora WOPI CheckFileInfo
Add the 7 MS-WOPI file URL properties (CloseUrl, DownloadUrl,
FileSharingUrl, FileVersionUrl, HostEditUrl, HostViewUrl, SignoutUrl)
to the Collabora fileinfo struct, mirroring the Microsoft struct's
existing fields and JSON tags. This is struct/SetProperties wiring
only; fileconnector.go population follows in a subsequent commit.
SignoutUrl is intentionally left unpopulated in CheckFileInfo (no
fileconnector.go change): the collaboration service has no OIDC
issuer/logout configuration to build a real sign-out URL from, so
Collabora reaches parity with Microsoft/OnlyOffice's existing
"field exists but is never populated" gap rather than introducing a
new one.
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): populate CloseURL and DownloadURL in CheckFileInfo
CloseURL and DownloadURL were never populated in CheckFileInfo for any
WOPI target (Microsoft, OnlyOffice, or Collabora), despite Microsoft's
struct having had these fields all along.
- CloseURL reuses the existing parentFolderURL (the same "folder
containing the file" URL already used for BreadcrumbFolderURL)
rather than building a second URL for the same concept. This flows
through the shared infoMap, so it now also reaches Microsoft and
OnlyOffice, both of which already declare KeyCloseURL in their
SetProperties switch; existing full-struct-equality test
expectations are updated accordingly.
- DownloadURL is built by a new createFileDownloadURL helper pointing
at this service's own GET /wopi/files/{fileid}/contents route,
authenticated with a freshly generated WOPI access token. It shares
its "generate token + build hashed-resource-id path + attach
access_token query param" logic with the existing template
createDownloadURL via an extracted createWopiResourceURL helper,
rather than duplicating it. Population is defensive: if WOPI token
generation fails, DownloadURL is simply omitted (logged) instead of
failing the whole CheckFileInfo request, mirroring the existing
TemplateSource pattern.
HostViewURL, HostEditURL, FileSharingURL, and FileVersionURL needed no
fileconnector.go change - they were already unconditionally computed
into infoMap; only Collabora's struct lacked the fields to receive
them (added in the previous commit).
Adds integration test coverage for: CloseURL/BreadcrumbFolderURL
reuse, HostEditURL vs HostViewURL distinctness, the DownloadURL route
pattern, and graceful omission of DownloadURL when WOPI token
generation fails (via ShortTokens with no store configured) without
the overall request failing.
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): complete Breadcrumb properties in Collabora WOPI CheckFileInfo
Add the four Breadcrumb* fields to the Collabora fileinfo struct that were
already present on Microsoft/OnlyOffice (BreadcrumbFolderName/URL just
needed struct wiring; BreadcrumbBrandName/URL needed new logic in
CheckFileInfo, derived from the CS3 StorageSpace Name/Root).
BreadcrumbBrandURL is withheld for public-share (anonymous) access, mirroring
the existing precedent for parentFolderURL/CloseURL, since it would expose
an internal space/resource id an anonymous user has no other way to reach.
BreadcrumbBrandName is just a display string and stays populated either way.
Also guards the new brand URL construction against a nil space root so it
degrades to an empty string instead of a misleading bare ".../f" URL when
no space info is available.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* test(collaboration): cover BreadcrumbBrandURL when space has no root
Add a new test case to verify that when a StorageSpace has a Name but
a nil Root, the BreadcrumbBrandName is populated while BreadcrumbBrandURL
remains empty, ensuring the nil-guard doesn't allow malformed URLs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add PostMessage properties to Collabora WOPI CheckFileInfo
Add ClosePostMessage, EditModePostMessage, EditNotificationPostMessage,
FileSharingPostMessage, and FileVersionPostMessage to the Collabora
fileinfo struct with SetProperties wiring and godoc comments, mirroring
what OnlyOffice already exposes.
Only EditModePostMessage is actually populated in CheckFileInfo, gated
to the Collabora target: the oCIS web frontend's iframe wrapper
(web-app-external/src/App.vue, shared by all WOPI targets) only has a
real postMessage handler for UI_Edit today. The other four flags are
left unset so Collabora falls back to the corresponding URL properties
(HostEditURL/HostViewURL/FileSharingURL/FileVersionURL, added in an
earlier task) instead of firing PostMessages nobody listens for.
Because OnlyOffice's SetProperties already implements these same keys,
the Collabora-only behavior requires an explicit `if` gate on
f.cfg.App.Product rather than an unconditional map write, to avoid
silently changing OnlyOffice's current (all-absent) behavior.
Signed-off-by: David Walter <david.walter@kiteworks.com>
* feat(collaboration): add Collabora-specific IsUserLocked and IsAdminUser to WOPI CheckFileInfo
Add the two Collabora-only WOPI CheckFileInfo properties: IsUserLocked
(applies coolwsd.xml locked_commands to the user) and IsAdminUser
(unlocks Collabora's server audit panel).
- IsUserLocked is derived from the existing "secure view" condition
already used to gate DisableExport/DisableCopy/DisablePrint/
WatermarkText (ViewMode == VIEW_MODE_VIEW_ONLY with a non-empty
ViewOnlyToken), applied regardless of public-share vs authenticated
user.
- IsAdminUser is derived from the CS3 user's Opaque.Map["roles"] JSON
array (the same raw data ocis-pkg/middleware/account.go lifts into
go-micro metadata), compared against
defaults.BundleUUIDRoleAdmin only - SpaceAdmin and other roles do
not qualify.
Both keys have no matching SetProperties case in Microsoft/OnlyOffice,
so they are silently dropped for those targets, consistent with the
existing pattern for other Collabora-only properties in this
connector. No new config surface was added, matching the scoping
approach used throughout this properties-gap series.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* test(collaboration): remove redundant Collabora omitempty test duplicates
TestCollaboraVersionOmitEmpty and TestCollaboraLastModifiedTimeOmitEmpty
fully duplicated the coverage already provided by
TestCollaboraJSONMarshallingIncludesVersion and
TestCollaboraJSONMarshallingIncludesLastModifiedTime (both already assert
JSON inclusion/omission via a shouldInclude flag). Removing the duplicates
also drops an unused `expected` table field flagged by the final
whole-branch review.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* docs(changelog): add changelog entry for Collabora WOPI CheckFileInfo gaps
Signed-off-by: David Walter <david.walter@kiteworks.com>
* test(collaboration): fix checkFileInfo acceptance tests for ReadOnly derivation
Four "check file info with different mode(s)" scenario outlines
(onlyOffice/fakeOffice, personal space and project space) hardcoded
"ReadOnly": {"const": false} for every view mode. That was accurate only
because ReadOnly was never actually populated in CheckFileInfo before this
PR (it silently defaulted to Go's zero value). Now that ReadOnly correctly
reflects whether the WOPI session grants write access
(ReadOnly = ViewMode != READ_WRITE, the exact negation of UserCanWrite),
"view" and "read" mode responses correctly report ReadOnly: true, which
these tests now assert via a new "read-only" Examples column instead of a
static const.
The "check file info with different view-mode (collabora)" scenario is
unaffected: it never asserted ReadOnly in its schema.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* revert(collaboration): remove X-COOL-WOPI-Timestamp PutFile conflict detection
CI on owncloud/ocis PR #12593 reproducibly failed the e2e test
web/tests/e2e/specs/app-provider/officeSuites.spec.ts:17:3 "create an
OpenDocument file with Collabora" across two independent full CI runs,
timing out after 180s behind a Collabora "document conflict" popup that
intercepts all clicks.
Server logs showed the new PutFile conflict check firing on literally
the first save of a freshly-created document, with a consistent ~8s gap
between the client's cached X-COOL-WOPI-Timestamp and the server's
current mtime that never resolved across 6+ retries over 3+ minutes.
This is most likely oCIS's async post-processing (search indexing,
thumbnailing, etc.) legitimately bumping the file's mtime shortly after
creation - something this comparison can't distinguish from a real
edit conflict, and which Collabora's client doesn't recover from
automatically.
Revert just the conflict-detection portion of task 02: the
coolWopiTimestamp parameter on ContentConnectorService.PutFile / its
implementation, the X-COOL-WOPI-Timestamp header handling in
HttpAdapter.PutFile, and NewResponseCOOLConflict, plus their tests and
mock signatures. The LastModifiedTime WOPI property (and everything
else task 02 added) is untouched and remains fully intact.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* test(web): add e2e Playwright coverage for WOPI CheckFileInfo properties
Adds dedicated Playwright specs, each covering both Collabora and
OnlyOffice, for the WOPI CheckFileInfo properties this PR added that
have a genuinely observable, already-proven-safe browser-level signal:
- wopiReadOnly.spec.ts: false for the file owner, true for a
view-only share recipient (via the existing canEditCollaboraDocument/
canEditOnlyOfficeDocument-backed userShouldNotBeAbleToEditContentOfResources
step).
- wopiSupportsUpdate.spec.ts: a new document created via the office
suite's own "New" menu (PutRelativeFile) persists its content across
a reopen.
- wopiVersionAndLastModifiedTime.spec.ts: an edit saved by one actor is
visible to a second actor opening the file afterward, rather than a
stale cached copy.
- wopiCloseUrl.spec.ts: closing the editor navigates the top-level page
back into the files app.
All four are built exclusively from step-level helpers already proven
reliable elsewhere in this suite (officeSuites.spec.ts, secureView.spec.ts)
- no new selectors into Collabora's or OnlyOffice's own iframe DOM.
Not added: dedicated e2e tests for BreadcrumbBrandName/Url,
EditModePostMessage, IsUserLocked, and IsAdminUser. CheckFileInfo is a
server-to-server call the office suite's own backend makes directly to
the collaboration service - it is never visible to the browser, so
Playwright cannot observe the JSON response for any property. These
four also have no independently observable browser effect without
either inventing unverified selectors into third-party iframe internals
(breadcrumb bar, edit-mode button) or Collabora-side configuration
(locked_commands, audit panel) this test environment doesn't set up.
They remain correctly covered by the Go unit/integration tests
(fileinfo/collabora_test.go, fileconnector_test.go) and the
tests/acceptance/features/apiCollaboration/checkFileInfo.feature
acceptance suite, which assert the actual JSON response server-side.
An initial IsAnonymousUser spec was written and dropped after review:
it only asserted that content loads, which IsAnonymousUser does not
gate, making it indistinguishable from a regression (already covered
correctly at the Go level in fileconnector_test.go).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(web): reformat wopiVersionAndLastModifiedTime.spec.ts for prettier
pnpm check:format (web-build-test CI job) flagged the test.describe()
call: its 3 arguments (title, options, callback) didn't fit within
this repo's printWidth 100 on one line, so prettier expects them
wrapped one per line. Reformatted to match and reindented the
describe block body accordingly. No logic change.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(collaboration): address PR #12593 review findings
- Restructure the VIEW_ONLY watermark check to nest inside the
ViewOnlyToken check instead of repeating the condition, per
jvillafanez's review comment.
- Add a reva token mint/dismantle round-trip test covering the admin
role Opaque entry, exercising the real JWT serialization seam
IsAdminUser depends on rather than only direct context injection,
per DeepDiver1975's review.
- Correct the changelog entry: ReadOnly/CloseUrl (and DownloadUrl for
Microsoft) already had matching `case` handling in microsoft.go/
onlyoffice.go, so populating them unconditionally changes those
targets' output too, not just Collabora's. Only IsUserLocked/
IsAdminUser are genuinely Collabora-only.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: David Walter <david.walter@kiteworks.com>
---------
Signed-off-by: David Walter <david.walter@kiteworks.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: Juan Pablo Villafañez <jpvillafanez@izertis.com>
* test: [OCISDEV-861] pin public-link visibility in unfiltered share listings
ListPublicShares issued one gateway Stat per public link not created by the
calling user, which exceeded the request deadline on tenants with thousands of
links. The fix lands in reva; these scenarios pin the user-visible contract so
that any future attempt to replace the permission check cannot silently change
who sees which links.
Adds one OCS scenario, deliberately untagged so it also runs in reva's CI, and
three Graph scenarios covering /me/drive/sharedByMe: a space member sees a
co-member's link, a non-member does not, and a non-member holding ListGrants on
the individual resource does.
Signed-off-by: Lukas Hirt <info@hirt.cz>
* test: cover more space roles and reuse standard user in sharedByMe scenarios
Extends the "space member sees link shares" scenario to cover Space
Editor and Space Viewer in addition to Manager, and swaps Carol for
Brian in the non-member scenarios since Brian is already provisioned
in the feature's Background, dropping a redundant creation step.
Signed-off-by: Lukas Hirt <info@hirt.cz>
---------
Signed-off-by: Lukas Hirt <info@hirt.cz>
* test(apiGraphGroup): add acceptance test for configurable LDAP group object class
* test(apiGraphGroup): make LDAP object class test portable across test environments
* test: use multilines for message assertion
A MOVE whose source and destination resolve to the same resource is now
answered with 204 No Content server side instead of a confusing 403 or
404, and instead of 409 Conflict on the id based dav route, so every
client behaves the same way. The no-op still requires the move
permission.
The server-side guard lives in reva (owncloud/reva#708 and the follow-up
owncloud/reva#713, which moves the guard above the recursion checks so it
is also reached when the request addresses the resource by its id).
Pulled in here by bumping reva to v2.0.0-20260813121157-d386075a0421.
vendor/ was regenerated with `go mod vendor`; no hand edits.
On the test side the @issue-1976 tags are dropped from the five MOVE
feature files and the corresponding entries are removed from both
expected-failures lists. Scenario Outlines that mix roles with and
without the move permission parameterize the expected status in an extra
http-status-code Examples column rather than being split into duplicate
scenarios. The gherlint newline_before_scenario rule is configured as
["error", 2, true], counting tag lines toward the total, so the eight
scenarios that lost their tag get back the blank line it occupied.
Drop the "viewer" row from the same-name Examples table in
moveByFileId.feature: "viewer" is not a valid space role for a
permissionsRole invitation, so the step errored with
Role 'viewer' not found, and the "Space Viewer" row already covers
the 403.
* test(ci): run test on k8s deployment
* chore: update authapp in config
* chore: update storageusers in config
* chore: update version and envs
* chore: normalize service name
* test: add test to check vault mode capabilities endpoint response
Signed-off-by: Prajwol Amatya <prajwolamatya11@gmail.com>
* test: add cleanup for Keycloak related configs after each test
Signed-off-by: Prajwol Amatya <prajwolamatya11@gmail.com>
* test: use ocs version 2
Signed-off-by: Prajwol Amatya <prajwolamatya11@gmail.com>
---------
Signed-off-by: Prajwol Amatya <prajwolamatya11@gmail.com>
