-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Closed
Closed
Copy link
Labels
Description
Steps to reproduce
From PR #38290 test scenarios: tests/acceptance/features/apiProvisioning-v1/disableUser.feature
Scenario: getting public link share shared by disabled user using the new public WebDAV API
Given user "Alice" has been created with default attributes and skeleton files
And user "Alice" has created a public link share with settings
| path | /textfile0.txt |
| permissions | read |
And user "Alice" has been disabled
When the public downloads the last public shared file using the new public WebDAV API
Then the HTTP status code should be "404"
Scenario: getting public link share shared by disabled user using the old public WebDAV API
Given user "Alice" has been created with default attributes and skeleton files
And user "Alice" has created a public link share with settings
| path | /textfile0.txt |
| permissions | read |
And user "Alice" has been disabled
When the public downloads the last public shared file using the old public WebDAV API
Then the HTTP status code should be "200"
And the same for tests/acceptance/features/apiProvisioning-v1/disableUser.feature
Expected behaviour
The results should be consistent. When user "Alice" is disabled, the the public link share that was already made by user "Alice" should either be accessible. or not accessible.
Actual behaviour
But with the new public WebDAV API it is not accessible, and with the old public WebDAV API it is accessible.
See comment #38291 (comment) - the root problem seems to be the value of file_target in the response to a public link share create request.
Server configuration
CI with current core master.
Reactions are currently unavailable