* test(coreApiWebdavUploadTUS): assert etag and permissions on the finalizing TUS chunk
The chunked TUS finalize returns OC-ETag, ETag and OC-Perm since
https://github.com/opencloud-eu/reva/pull/718, so a client no longer
needs a follow-up PROPFIND for the new etag and permissions. Add a
scenario asserting these headers on the finalizing chunk, reusing
existing step definitions (the etag is a dynamic quoted hash, hence the
header-regex assertion).
Verified locally red->green: red on stock (headers absent), green on an
opencloud built on a reva carrying that change, on posix and decomposed.
https://github.com/opencloud-eu/opencloud/issues/2409
* test(coreApiWebdavUploadTUS): assert exact OC-Perm and tighten etag regex
---------
Co-authored-by: v.scharf <v.scharf@opencloud.eu>
opencloud-eu/reva#655 changes the TUS create response for an invalid name
from 412 to 400. Update the invalid-name scenario to match.
Each example now carries its own expected status in an <http-status-code>
column. Names that fail ValidateName expect 400. The three folder/file rows
stay 412: filename() applies path.Base first, so "folder/file" becomes the
valid leaf "file" and never reaches the changed branch.
lowLevelCreationExtension.feature is unchanged; its missing-Upload-Length
case still returns 412.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* resharing.feature: Used sharingNG for sharing in given step
* unlockFiles.feature: Used sharingNG for sharing in given step
* apiSpacesShares suite: Used sharingNG for sharing in given step
* acceptShares.feature: Used sharingNG for sharing in given step
* uploadFile.feature: Used sharingNG for sharing in given step
* coreApiWebdavUploadTUS suite: Used sharingNG for sharing in given step
* tag.feature: Used sharingNG for sharing in given step
* coreApiShareOperationsToShares2 suite: Used sharingNG for sharing in given step
* updateShare.feature: Used sharingNG for sharing in given step
* Fixed line numbers in expected failure
* do not use spacesContext
* skip sharing tests in reva
* update expected failure list
* do not cleanup status codes
* skip shares tests in reva
* update expected failure list