[tests-only] [full-ci] Adjust public link test code

[phil-davis]

Description

WIP

This is the acceptance test code that was refactored for PR #40264 - a lot of it is good refactoring to do anyway.

The code looks good for current master behavior. But we can keep this PR in Draft until after release 10.11 happens and is merged back. I don't really want to refactor this much test code in master right now.

Note: it seems that we can currently use the API to create a public link of a single file that has write access, and that "the public" can use the link to update the content of the file. So, at the API level, this feature already exists. There is just no UI to do it on the classic web UI.

ToDo: check and document the API request sequence for making and using a write-enabled public link of a single file.

How Has This Been Tested?

CI

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Database schema changes (next release will require increase of minor version instead of patch)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Technical debt
• [x] Tests only (no source changes)

Checklist:

• [ ] Code changes
• [ ] Unit tests added
• [ ] Acceptance tests added
• [ ] Documentation ticket raised:
• [ ] Changelog item, see TEMPLATE

[phil-davis]

I can do this sequence of API requests in the current oC10 core master:

1. create a file in my "phil" account:

curl -u phil:phil -X PUT http://172.17.0.1:8080/remote.php/webdav/somefile.txt -d "some text"

2. create a public link share of the file, asking for permissions 15 (all except for reshare):

curl -v -u phil:phil POST http://172.17.0.1:8080/ocs/v1.php/apps/files_sharing/api/v1/shares -d "permissions=15&path=somefile.txt&shareType=3"

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>100</statuscode>
  <message/>
  <totalitems></totalitems>
  <itemsperpage></itemsperpage>
 </meta>
 <data>
  <id>1814</id>
  <share_type>3</share_type>
  <uid_owner>phil</uid_owner>
  <displayname_owner>phil</displayname_owner>
  <permissions>3</permissions>
  <stime>1661767716</stime>
  <parent/>
  <expiration/>
  <token>pHWM10ZCgjppw4l</token>
  <uid_file_owner>phil</uid_file_owner>
  <displayname_file_owner>phil</displayname_file_owner>
  <additional_info_owner/>
  <additional_info_file_owner/>
  <path>/somefile.txt</path>
  <mimetype>text/plain</mimetype>
  <storage_id>home::phil</storage_id>
  <storage>3244</storage>
  <item_type>file</item_type>
  <item_source>2147511072</item_source>
  <file_source>2147511072</file_source>
  <file_parent>2147506056</file_parent>
  <file_target>/somefile.txt</file_target>
  <name/>
  <url>http://172.17.0.1:8080/index.php/s/pHWM10ZCgjppw4l</url>
  <mail_send>0</mail_send>
  <attributes/>
 </data>
</ocs>

3. get the content using the public link token:

curl -v -u pHWM10ZCgjppw4l: http://172.17.0.1:8080/public.php/webdav/
some text

4. update the content using the public link token:

curl -v -u pHWM10ZCgjppw4l: -X PUT http://172.17.0.1:8080/public.php/webdav/ -d "updated content"
returns 204 No Content - good

5. get the content again using the public link token:

curl -v -u pHWM10ZCgjppw4l: http://172.17.0.1:8080/public.php/webdav/
updated content

The content did get updated.

@DeepDiver1975 the feature seems to already exist at the API level - is that correct/expected?

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information