release_2.14 branch in owncloud/androidoc-android-2.14 in HEAD commit of release_2.14 branch, in owncloud/android1.0.4 in HEAD commit of release_1.0.4 branch, in owncloud/androidrelease_1.0.4 in owncloud/android-library, into masterrelease_2.14 in owncloud/android, into masterrelease_1.0.4 branch into stable, in owncloud/android-libraryrelease_2.14 branch tag into stable, in owncloud/androidRelease communication (and wizard steps):
Regression test:
https://github.com/owncloud/QA/blob/master/Mobile/Android/Release_2.14.0/Regression_2.14.md
Logs from logcat are duplicated.
Current: Duplicated logs
Expected: Every log appears once
Nexus 5X v8
Interesting, in my version I don't have duplicated entries. (I use a Pixel 2 Android Q)
Additional I don't have a Nexus 5X.
Maybe you can run my version on a Nexus 5X too.
If with this version there are duplicated too, then it's located to the device.
If not, it's probably your apk. My apk is at least public !
My apk is at least public !
Yeah, thats a disadvantage of the bitrise.io CI we're using for a while. I'd love to have the CI errors and builds public available. @jesmrec Could you post the link to the "Public install page" manually?
@hannesa2 Send me your mail, I'd love to invite you to the bitrise project.
@michaelstingl you see it in commits author.
Btw, I see a lot of disadvantages with bitrise. I can't improve/test it with a pull request and it's no more public.
I will stay will Travis, and yes: with x86 tests with Travis.
With Travis I can publish any intermediate release too.
https://github.com/owncloud/android/pull/2746 I found the twice logs
We worked with Travis for long time. Disadvantages of Travis from our side:
For these main reasons, the team decided to move to another tool. BitRise has also itsown inconvenients (mainly reagarding UI tests), that we are working to fix from our side in several PRs you will find in the list. Currently tests are passing in BitRise, but there are some concerns to agree, in which it is interesting to get more info, like the one i ask you here: https://github.com/owncloud/android/pull/2737#issuecomment-559785273
We can check if BR allows to make public the final artifacts, if it is really interesting for the community.
Finally, this thread is for the Release 2.14. If you want to comment/discuss other stuff, please use a different issue. Thanks.
2746 I found the twice logs
thanks, i will check.
I can't improve/test it with a pull request
Related? https://devcenter.bitrise.io/tips-and-tricks/use-bitrise-yml-from-repository/
Current: Files starts to uploads, and finally appears as uploaded (they aren't really). If you browse in the containing folder (created in 2.), app crashes.
Expected: Files are not uploaded with a correct error, due to lack of space.
Xiaomi MiA9 v9
NOTE: This problem is already in 2.13.1, so it is not a regression. It is a nice to have since crashes are not desirable.
Current: Item is not removed from the list
Expected: Item removed from the list, because the link was removed.
The difference here is the location of the file/folder. If it is located in root folder, it is removed from the list after removing the link.
Xiaomi MiA2 v9
(5)
Share by link a file/folder that is not in root folder
Open "Shared by link" section in the drawer
Long press on the recent shared item and select share icon on toolbar
Remove the share link created in 1.
This is related to https://github.com/owncloud/android/pull/2705#issuecomment-561141380.
When performing the steps you describe, the share is properly removed but the file/folder is not synchronized in "Shared by link" view so still has the shared flag enabled; to make it disappear we would need to discover it (browse to it) using the "All files" view.
It's not a good behaviour but I think there's nothing we can do without synchronizing the whole files tree
Thanks for the explanation... it's a feature not a bug :D. Will mark as won't fix
Current: When long pressing the item in user2's list, the option share is enabled in the toolbar
2.13.1: When long pressing the item in user2's list, the option share is not enabled in toolbar, because such content is not allowed to be reshared.
Nexus 6P v7
10.3.1
(4)
- Set a low qouta in the Users panel, f. ex 30MB
- Create a folder in root, and upload inside several files which size exceeds the quota
Current: Files starts to uploads, and finally appears as uploaded (they aren't really). If you browse in the containing folder (created in 2.), app crashes.
Expected: Files are not uploaded with a correct error, due to lack of space.
Xiaomi MiA9 v9
NOTE: This problem is already in 2.13.1, so it is not a regression. It is a nice to have since crashes are not desirable.
I've fixed the crash but the files will be first uploaded and removed later, that's the app behaviour for a long time. To avoid the upload we would need extra effort (perform an extra operation to check the available space since I'm not sure the upload operation itself retrieves that kind of information). Anyway, should be addressed in a separate issue, not as a part of this release.
I've fixed the crash but the files will be first uploaded and removed later, that's the app behaviour for a long time. To avoid the upload we would need extra effort (perform an extra operation to check the available space since I'm not sure the upload operation itself retrieves that kind of information). Anyway, should be addressed in a separate issue, not as a part of this release.
not a problem. If the bug itself is not a regression, the behaviour you describe is even older. The point is, that after performing the action, the app is consistent with the final result. Maybe more desirable to avoid the uploads (saving time and bandwidth), but as you said, this is a separate feature. Fixing the crash is more than enough here.
Current: File starts to uploads. Finally, in uploads view appears as completed. But, file is not in the file list.
2.13.1: Error in uploads view: Permissions error.
Nexus 6P v7
(7)
- User1 shares a folder with User2, with no "create" permission
- User2 uploads a file inside the shared folder
Current: File starts to uploads. Finally, in uploads view appears as completed. But, file is not in the file list.
2.13.1: Error in uploads view: Permissions error.Nexus 6P v7
I've just noticed this behaviour in 2.13.1:
In 2.14 the behaviour is the same except there's no crash when browsing to the shared folder. So I would say is not a regression, we could address it along with synchronization within new architecture
Current: in mitmproxy you will see that the query performed in the step 2 is made with the Account 1 credentials.
Expected: step 2 should use Account 2 credentials.
Nexus 5X v8.1.0
In 2.14 the behaviour is the same except there's no crash when browsing to the shared folder. So I would say is not a regression, we could address it along with synchronization within new architecture
Could you create a new issue and point it from the architecture epic out?
Regression stage finished with everything fixed. Let's go with the upgrade tests
Checks :
Current: app crashes
Expected: list of shares
Samsung S9 v9, Nexus 5X v8, Nexus 6P v7
commit 42eb9f1e
Upgrading problem is fixed. So, testing tasks are done and the 2.14 version is ready to release.
Great job, team!!!