Error when user upload files into the folder Shares

[ScharfViktor]

Describe the bug

User try upload file/folder or create new folder into folder Shares.
A test is written that demonstrates the error. The test will work when the bug is fixed

Steps to reproduce

1. User 1 shared file to user 2 (no matter what rights)
2. User 2 accept file and go to folder Shares
3. User 2 try to upload file/folder or create new folder

Expected behavior

If the user cannot upload or create items, the webUI should not offer the button.

Actual behavior

User cannot upload or create new object in the folder Shares

Setup

Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=v1.9.0 reachable at https://localhost:9200
BRANCH=uploadIntoShared

[phil-davis]

I wonder how ownCloud10 should behave?

• set share_folder to "Shares" in config.php
• create users Alice and Brian
• neither Alice nor Brian see a folder called "Shares"
• Alice shares a resource "file.txt" with Brian
• Brian now sees a folder "Shares" containing "file.txt"
• Brian tries to upload a file "myFile.txt" into "Shares"

What should happen?

Should

1. the upload succeed, and Brian will have a file of his own, and a received shared file in the "Shares" folder?
   Or
2. should the upload fail?

@pmaier1

If (1) then I will have more questions about what should happen if Alice deletes the share, and Brian no longer has any received shares.

[ScharfViktor]

After discussing with @micbar, we found the problem.
The user must not have rights to create objects in the folder "Shares". Button "New" should be disabled.

Expected behavior:
request curl 'https://localhost:9200/remote.php/webdav/Shares' \ -X 'PROPFIND' \
should return read rights <oc:permissions>S then web will block the button "New"

Expected test result 5566 will be also changed

[phil-davis]

In oC10 API and UI a user can create their own files/folders in the "Shares" folder. Those persist, even when the user no longer has any received shares.

What do we do about the existing oC10 behavior?

Does "web" need to understand that on oC10 the "Shares" folder can be written to directly, but on OCIS it cannot be written to directly?

[micbar]

Does "web" need to understand that on oC10 the "Shares" folder can be written to directly, but on OCIS it cannot be written to directly?

Web will understand the correct webdav permissions

Needs a backend fix

[pascalwengerter]

Should we move this issue to the oCIS repo then? @micbar

[micbar]

already there #2322

[pmaier1]

Regarding #2322 (comment): I don't know how far the discussions outside of this ticket went. In the scenario you describe, I would expect

• in oCIS that the upload fails because the "Shares" folder is a read-only jail for incoming shares.
• in oC 10 that the upload succeeds because the folder is (just) a default location for incoming shares. If Brian no longer has any received shares, the folder would stay as it is (containing uploaded files, not containing any received shares).

Does that make sense for everyone or am I missing something?

[phil-davis]

I will adjust the API test expectations - one scenario for oC10 expected behavior and another scenario for OCIS expected behavior.

And then we will need 2 different scenarios in web that have the expected behavior of the UI when running with an oC10 server and with an OCIS server - I will leave that for @ScharfViktor to write and tag them so that they run in the appropriate pipelines in CI.

[micbar]

@ScharfViktor @phil-davis I changed the "expected behavior"

[micbar]

I have a PR in Reva which fixes it.

CURL

Request

curl --location --request PROPFIND 'https://localhost:9200/dav/files/einstein/Shares' \
--header 'Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ=='

Result

<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
    <d:response>
        <d:href>/dav/files/einstein/Shares/</d:href>
        <d:propstat>
            <d:prop>
                <oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmY0MjQ4MDBmLTc5YjItNDZhNi05NzQ2LTFmM2I4MmEwYjViYw==</oc:id>
                <oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmY0MjQ4MDBmLTc5YjItNDZhNi05NzQ2LTFmM2I4MmEwYjViYw==</oc:fileid>
                <d:getetag>&#34;05e827b715f0da007b7adc800703bb1e&#34;</d:getetag>
                <oc:permissions></oc:permissions>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <d:getlastmodified>Tue, 27 Jul 2021 14:38:25 GMT</d:getlastmodified>
                <oc:favorite>0</oc:favorite>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/dav/files/einstein/Shares/NewFolder/</d:href>
        <d:propstat>
            <d:prop>
                <oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjNjY2RhNzUyLWFiMWQtNGEzMS05YWFkLWVjNjA2ZmY4MDZkYw==</oc:id>
                <oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjNjY2RhNzUyLWFiMWQtNGEzMS05YWFkLWVjNjA2ZmY4MDZkYw==</oc:fileid>
                <d:getetag>&#34;74d129b6a9a38d48976c1dee64a9bd53&#34;</d:getetag>
                <oc:permissions>S</oc:permissions>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <d:getlastmodified>Tue, 27 Jul 2021 14:37:49 GMT</d:getlastmodified>
                <oc:favorite>0</oc:favorite>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

WebUI