You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior:
either:
a) at step 2 there should be an error response (4nn code) and the share is not created - because "the system" cannot create the share exactly as requested.
or
b) at step 2 the share is created with all permissions, including public upload. So it is "ready" to allow public upload if the system-wide setting shareapi_allow_public_upload is enabled in future.
Take your pick.
Note that if there are current shares with public upload permissions, and shareapi_allow_public_upload is disabled, then those shares "sit there" still and are just non-functional (good). If shareapi_allow_public_upload is later enabled, then those shares "come to life" again.
For that reason, I am inclined to behavior (b) - that you can disable front-end behavior like shareapi_allow_public_upload but still setup shares. Then when you are ready you can enable the front-end behavior and "the system comes to life".
The text was updated successfully, but these errors were encountered:
GitMate.io thinks possibly related issues are #18110 (upload in public shared folder creates errors ), #1367 ("Create" permission hidden when folder is first shared), #20839 (Sharing a file allows you to set create permissions), #22739 (Sharing permission issue), and #17486 (Allow folder creation in public share).
Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.
shareapi_allow_public_upload
Actual behavior:
shareapi_allow_public_upload
Scenario is:
https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharing-v1/uploadToShare.feature#L244
Expected behavior:
either:
a) at step 2 there should be an error response (
4nn
code) and the share is not created - because "the system" cannot create the share exactly as requested.or
b) at step 2 the share is created with all permissions, including public upload. So it is "ready" to allow public upload if the system-wide setting
shareapi_allow_public_upload
is enabled in future.Take your pick.
Note that if there are current shares with public upload permissions, and
shareapi_allow_public_upload
is disabled, then those shares "sit there" still and are just non-functional (good). Ifshareapi_allow_public_upload
is later enabled, then those shares "come to life" again.For that reason, I am inclined to behavior (b) - that you can disable front-end behavior like
shareapi_allow_public_upload
but still setup shares. Then when you are ready you can enable the front-end behavior and "the system comes to life".The text was updated successfully, but these errors were encountered: