[stable10] Release 10.2.0 rebased#35262
Conversation
80babf0 to
74e4058
Compare
|
drone is not starting. There is currently some general problem with drone. |
74e4058 to
6f69def
Compare
|
Rebased again just now to trigger drone CI. |
6f69def to
eb9b6b5
Compare
Codecov Report
@@ Coverage Diff @@
## stable10 #35262 +/- ##
==============================================
+ Coverage 64.52% 64.61% +0.09%
- Complexity 20080 20089 +9
==============================================
Files 1289 1289
Lines 76947 76966 +19
Branches 1299 1300 +1
==============================================
+ Hits 49650 49734 +84
+ Misses 26916 26848 -68
- Partials 381 384 +3
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## stable10 #35262 +/- ##
==============================================
+ Coverage 64.54% 64.64% +0.09%
- Complexity 20080 20089 +9
==============================================
Files 1289 1289
Lines 76923 76943 +20
Branches 1299 1300 +1
==============================================
+ Hits 49651 49738 +87
+ Misses 26891 26821 -70
- Partials 381 384 +3
Continue to review full report at Codecov.
|
The uploader is expecting the progress bar element to be in the DOM when created. This fix makes sure to append the PublicUploadView's element to the DOM before rendering it.
…load Remove share permission check from the file upload js file. Signed-off-by: Sujith H <sharidasan@owncloud.com>
File uploads should also be checked if they are aborted or not. This would help to check if the file is aborted or not. If aborted then it would be cleared from the list. Signed-off-by: Sujith H <sharidasan@owncloud.com>
When user tries to change the permission from permission 15 to permission 7 ( i.e, View/Download/ Upload), the permissions are not updated properly. The reason for this is due to the overwriting of newpermission variable with permission 15. This changeset removes the overwriting to newpermission variable. Signed-off-by: Sujith H <sharidasan@owncloud.com>
Remove update permission for Download/View/Upload option for public link. And hence the behaviour of public links created using this option has changed. 1. User cannot delete the files/folders inside this public link. 2. User cannot update the files which are already present in the public link 3. User cannot rename files. Signed-off-by: Sujith H <sharidasan@owncloud.com>
eb9b6b5 to
8402aed
Compare
|
I rebased again to try and get clean CI. It would be good to get this PR merged. |
… upload check The public link edit template was outside public upload check. And hence for creating the public link for files the full permission option was shown. This change tries to address the issue. Signed-off-by: Sujith H <sharidasan@owncloud.com>
Signed-off-by: Patrick Jahns <github@patrickjahns.de>
Signed-off-by: Patrick Jahns <github@patrickjahns.de>
Signed-off-by: Patrick Jahns <github@patrickjahns.de>
8402aed to
7fe2d2c
Compare
Description
resolve reported conflicts along the way...
The
git rebasecommand happily drops commits where the code is already exactly instable10. So that removes a lot of "rubbish" from the list.The only conflicts were in
README.mdandtests/acceptance/features/webUISharingPublic/shareByPublicLink.feature- both of these were easy to sort out and do not effect run-time code anyway.Motivation and Context
There is a mix of commits in
release-10.2.0branch. Some of them are also already instable10and some are not. There are other PRs that did not make it into10.2and are just instable10branch. When doing just a "straight" PR online fromrelease-10.2.0branch tostable10there are various conflicts and it shows a long list of many commits that are actually instable10- e.g. see PR #35261This PR tries to tidy things up a bit to make it easier to comprehend...
How Has This Been Tested?
CI
Types of changes
Checklist:
Open tasks: