cloud/ocis
1
0
Fork 0
mirror of https://github.com/owncloud/ocis.git synced 2026-10-23 23:29:02 +03:00
Code Activity
Files
test-cli-postprocessing-resume
ocis/tests/acceptance/features/apiCollaboration/checkFileInfo.feature
David Walter 4d9c46f3a7 feat(collaboration): close WOPI property gaps (#12593) 
* 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>
2026-08-25 18:01:56 +02:00

1886 lines
53 KiB
Gherkin
Raw Permalink Blame History

Feature: check file info with different wopi apps
As a user
I want to request file information on wopi server
So that I can get all the information of a file
Background:
Given user "Alice" has been created with default attributes
Scenario: check file info with fakeOffice
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "FakeOffice"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": false
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Scenario: check file info with collabora
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "Collabora"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": false
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": true
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": true
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Scenario: check file info with onlyOffice
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "OnlyOffice"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"HostEditUrl",
"FileSharingUrl",
"FileVersionUrl"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"DisablePrint": {
"const": false
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
},
"BreadcrumbFolderName": {
"const": "Alice Hansen"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
},
"FileSharingUrl": {
"type": "string"
},
"HostEditUrl": {
"type": "string"
},
"FileVersionUrl": {
"type": "string"
}
}
}
"""
Scenario Outline: check file info with different mode (onlyOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "OnlyOffice" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"HostEditUrl",
"FileSharingUrl",
"FileVersionUrl"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": <read-only>
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": <user-can-rename>
},
"UserCanWrite": {
"const": <user-can-write>
},
"DisablePrint": {
"const": <disable-print>
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
},
"BreadcrumbFolderName": {
"const": "Alice Hansen"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
},
"FileSharingUrl": {
"type": "string"
},
"HostEditUrl": {
"type": "string"
},
"FileVersionUrl": {
"type": "string"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename | read-only |
| view | true | false | false | true |
| read | false | false | false | true |
| write | false | true | true | false |
Scenario Outline: check file info with different mode (fakeOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "FakeOffice" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": <read-only>
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": <user-can-rename>
},
"UserCanWrite": {
"const": <user-can-write>
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": <disable-print>
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename | read-only |
| view | true | false | false | true |
| read | false | false | false | true |
| write | false | true | true | false |
Scenario Outline: check file info with different view-mode (collabora)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" checks the information of file "textfile0.txt" of space "Personal" using office "Collabora" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": <disable-print>
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": <user-can-write>
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": <user-can-rename>
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename |
| view | true | false | false |
| read | false | false | false |
| write | false | true | true |
Scenario Outline: try to get file info using invalid file id with office suites
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
When user "Alice" tries to check the information of file "textfile0.txt" of space "Personal" using office "<office-suites>" with invalid file-id
Then the HTTP status code should be "401"
Examples:
| office-suites |
| Collabora |
| FakeOffice |
| OnlyOffice |
@issue-10097
Scenario Outline: try to get file info of deleted file with office suites
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | <office-suites> |
And user "Alice" has deleted file "/textfile0.txt"
When user "Alice" tries to get the information of the last opened file using wopi endpoint
Then the HTTP status code should be "404"
Examples:
| office-suites |
| Collabora |
| FakeOffice |
| OnlyOffice |
Scenario: get file info of restored file from trashbin (collabora)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | Collabora |
And user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has restored the file with original path "/textfile0.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": false
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": true
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": true
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Scenario: get file info of restored file from trashbin (fakeOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | FakeOffice |
And user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has restored the file with original path "/textfile0.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": false
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
}
}
}
"""
Scenario: get file info of restored file from trashbin (onlyOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | OnlyOffice |
And user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has restored the file with original path "/textfile0.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate"
],
"properties": {
"BaseFileName": {
"const": "textfile0.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"DisablePrint": {
"const": false
},
"BreadcrumbDocName": {
"const": "textfile0.txt"
},
"BreadcrumbFolderName": {
"const": "Alice Hansen"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
}
}
}
"""
Scenario: get file info after renaming file (onlyOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | OnlyOffice |
And user "Alice" has moved file "textfile0.txt" to "renamedfile.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate"
],
"properties": {
"BaseFileName": {
"const": "renamedfile.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"DisablePrint": {
"const": false
},
"BreadcrumbDocName": {
"const": "renamedfile.txt"
},
"BreadcrumbFolderName": {
"const": "Alice Hansen"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
}
}
}
"""
Scenario: get file info after renaming file (collabora)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | Collabora |
And user "Alice" has moved file "textfile0.txt" to "renamedfile.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "renamedfile.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": false
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": true
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": true
},
"BreadcrumbDocName": {
"const": "renamedfile.txt"
}
}
}
"""
Scenario: get file info after renaming file with (fakeOffice)
Given user "Alice" has uploaded file with content "hello world" to "/textfile0.txt"
And user "Alice" has sent the following app-open request:
| resource | textfile0.txt |
| space | Personal |
| app | FakeOffice |
And user "Alice" has moved file "textfile0.txt" to "renamedfile.txt"
When user "Alice" gets the information of the last opened file using wopi endpoint
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "renamedfile.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": false
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "renamedfile.txt"
}
}
}
"""
Scenario: check the information of a project space file with fakeOffice
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "FakeOffice"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": false
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "text.txt"
}
}
}
"""
Scenario: check the information of a project space file with collabora
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "Collabora"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": false
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": true
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": true
},
"BreadcrumbDocName": {
"const": "text.txt"
}
}
}
"""
Scenario: check the information of a project space file with onlyOffice
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "OnlyOffice"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": true
},
"UserCanWrite": {
"const": true
},
"DisablePrint": {
"const": false
},
"BreadcrumbDocName": {
"const": "text.txt"
},
"BreadcrumbFolderName": {
"const": "new-space"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
}
}
}
"""
Scenario Outline: check the information of a project space file with different modes (onlyOffice)
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "OnlyOffice" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"Version",
"BreadcrumbDocName",
"BreadcrumbFolderName",
"BreadcrumbFolderUrl",
"PostMessageOrigin",
"DisablePrint",
"UserFriendlyName",
"UserId",
"ReadOnly",
"UserCanNotWriteRelative",
"UserCanRename",
"UserCanWrite",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": <read-only>
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanRename": {
"const": <user-can-rename>
},
"UserCanWrite": {
"const": <user-can-write>
},
"DisablePrint": {
"const": <disable-print>
},
"BreadcrumbDocName": {
"const": "text.txt"
},
"BreadcrumbFolderName": {
"const": "new-space"
},
"BreadcrumbFolderUrl": {
"type": "string"
},
"PostMessageOrigin": {
"type": "string"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename | read-only |
| view | true | false | false | true |
| read | false | false | false | true |
| write | false | true | true | false |
Scenario Outline: check the information of a project space file with different modes (fakeOffice)
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "FakeOffice" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"OwnerId",
"Size",
"UserId",
"Version",
"SupportsCobalt",
"SupportsContainers",
"SupportsDeleteFile",
"SupportsEcosystem",
"SupportsExtendedLockLength",
"SupportsFolders",
"SupportsGetLock",
"SupportsLocks",
"SupportsRename",
"SupportsUpdate",
"SupportsUserInfo",
"UserFriendlyName",
"ReadOnly",
"RestrictedWebViewOnly",
"UserCanAttend",
"UserCanNotWriteRelative",
"UserCanPresent",
"UserCanRename",
"UserCanWrite",
"AllowAdditionalMicrosoftServices",
"AllowExternalMarketplace",
"DisablePrint",
"DisableTranslation",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserId": {
"type": "string"
},
"Version": {
"type": "string"
},
"SupportsCobalt": {
"const": false
},
"SupportsContainers": {
"const": false
},
"SupportsDeleteFile": {
"const": true
},
"SupportsEcosystem": {
"const": false
},
"SupportsExtendedLockLength": {
"const": true
},
"SupportsFolders": {
"const": false
},
"SupportsGetLock": {
"const": true
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"SupportsUpdate": {
"const": true
},
"SupportsUserInfo": {
"const": false
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"ReadOnly": {
"const": <read-only>
},
"RestrictedWebViewOnly": {
"const": false
},
"UserCanAttend": {
"const": false
},
"UserCanNotWriteRelative": {
"const": false
},
"UserCanPresent": {
"const": false
},
"UserCanRename": {
"const": <user-can-rename>
},
"UserCanWrite": {
"const": <user-can-write>
},
"AllowAdditionalMicrosoftServices": {
"const": false
},
"AllowExternalMarketplace": {
"const": false
},
"DisablePrint": {
"const": <disable-print>
},
"DisableTranslation": {
"const": false
},
"BreadcrumbDocName": {
"const": "text.txt"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename | read-only |
| view | true | false | false | true |
| read | false | false | false | true |
| write | false | true | true | false |
Scenario Outline: check the information of a project space file with different modes (collabora)
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" checks the information of file "text.txt" of space "new-space" using office "Collabora" with view mode "<mode>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"BaseFileName",
"DisablePrint",
"OwnerId",
"PostMessageOrigin",
"Size",
"UserCanWrite",
"UserCanNotWriteRelative",
"UserId",
"UserFriendlyName",
"EnableOwnerTermination",
"SupportsLocks",
"SupportsRename",
"UserCanRename",
"BreadcrumbDocName"
],
"properties": {
"BaseFileName": {
"const": "text.txt"
},
"PostMessageOrigin": {
"const": "%base_url%"
},
"DisablePrint": {
"const": <disable-print>
},
"OwnerId": {
"type": "string"
},
"Size": {
"const": 11
},
"UserCanWrite": {
"const": <user-can-write>
},
"UserCanNotWriteRelative": {
"const": false
},
"EnableOwnerTermination": {
"const": true
},
"UserId": {
"type": "string"
},
"SupportsLocks": {
"const": true
},
"SupportsRename": {
"const": true
},
"UserFriendlyName": {
"const": "Alice Hansen"
},
"UserCanRename": {
"const": <user-can-rename>
},
"BreadcrumbDocName": {
"const": "text.txt"
}
}
}
"""
Examples:
| mode | disable-print | user-can-write | user-can-rename |
| view | true | false | false |
| read | false | false | false |
| write | false | true | true |
Scenario Outline: try to get the information of a project space file using invalid file-id
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And using spaces DAV path
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "hello world" to "text.txt"
When user "Alice" tries to check the information of file "text.txt" of space "new-space" using office "<office-suites>" with invalid file-id
Then the HTTP status code should be "401"
Examples:
| office-suites |
| Collabora |
| FakeOffice |
| OnlyOffice |
@issue-10086
Scenario: check that '/app/list' doesn't contain 'application/octet-stream' MIME type
When user "Alice" sends HTTP method "GET" to URL "/app/list"
Then the HTTP status code should be "200"
And the response should not contain the following MIME types:
| application/octet-stream |
Scenario: check target extensions for template mime types
When user "Alice" sends HTTP method "GET" to URL "/app/list"
Then the HTTP status code should be "200"
And the app list response should contain the following template information for office "OnlyOffice":
| mime-type | target-extension |
| application/vnd.oasis.opendocument.spreadsheet-template | xlsx |
| application/vnd.oasis.opendocument.text-template | docx |
| application/vnd.oasis.opendocument.presentation-template | pptx |
| application/vnd.openxmlformats-officedocument.spreadsheetml.template | xlsx |
| application/vnd.openxmlformats-officedocument.presentationml.template | pptx |
| application/vnd.openxmlformats-officedocument.wordprocessingml.template | docx |
| application/vnd.ms-word.template.macroenabled.12 | docx |
| application/vnd.ms-powerpoint.template.macroenabled.12 | pptx |
| application/vnd.ms-excel.template.macroenabled.12 | xlsx |
And the app list response should contain the following template information for office "Collabora":
| mime-type | target-extension |
| application/vnd.oasis.opendocument.spreadsheet-template | ods |
| application/vnd.oasis.opendocument.text-template | odt |
| application/vnd.oasis.opendocument.presentation-template | odp |
View Git Blame Copy Permalink