-
Notifications
You must be signed in to change notification settings - Fork 667
Testing Scenarios 2.1
- The flow of when a login window was changed, so it would be nice to verify that we don't either: Enter an infinite loop of showing notifications since a login window is expected to end the loop (but would not happen in some cases) Or that a login window should be shown, but that a "can't login" notification is shown instead (for example if a Sign In button is pressed).
- A notification should be shown if the login credentials have been invalidated by the server, or at startup
- A login window should be shown if the user explicitly request to login, either through the new Sign In button in the account settings, either through the tray icon.
The client should work with a server setup with file firewall properly. To test set, set up a file firewall on the server, configure some cases where the firewall refuses some files to be uploaded and check if the client displays proper error messages and such.
- Share window should not open when sharing is disabled
- If used on server < 8.2 only the links sharing should show
- Try to share with multiple
- Users
- Groups
- Federated users
- Add and remove a share multiple times should work
- Searching for users/groups in the searchbar should not display users/groups already shared with
- Changing permissions should work (you can verify on the webinterface if it actually changes)
- You can't share with yourself (should not show up in search list)
Acceptance criteria: Local repository discovery does not take noticeable time any more. Uploads of new files start immediately.
Note: This was not implemented?!
- If the free disk space is below a critical amount (C), syncs won't start.
- If the free disk space falls below a critical amount (C) at the start of a sync download, the sync is aborted.
- If a download would reduce the free disk space below a buffer amount (B), the download is skipped.
- Skipped downloads produce an error once and are blacklisted - they only appear as soft errors from then on.
Test hints:
- The default for the critical amount (C) is 50 MB and can be overridden with the
OWNCLOUD_CRITICAL_FREE_SPACE_BYTESenvironment variable (the value is in bytes). - The default for the buffer amount (B) is 250 MB and can be overridden with
OWNCLOUD_FREE_SPACE_BYTESenvironment variable.
Possible test cases:
- Set
OWNCLOUD_CRITICAl_FREE_SPACE_BYTESto a value that's around, but less than, the current free space. Check that up and downloads work. Check that once the threshold is passed, no syncs are done. - Set
OWNCLOUD_FREE_SPACE_BYTESto a value that's around, but less than, the current free space. Check that small downloads still work, but files that'd make it cross the threshold are not downloaded.
When a directory is shared as read-only, the files inside will be marked as such. When the share permissions are changed, the file permissions are updated.
When an .eml file is uploaded, its content checksum is stored in the database. If the file is later touched (modification time changes, content does not) it is not uploaded again. The client detects that by computing the content checksum again and comparing it to the checksum of the last upload.
All files that can be represented by the client OS and its filesystem should now be syncable to the server, unless there is a server side limitation. In this case, the server will show an error, and then resume with an informational icon. If a file cannot be uploaded due to other reasons (file firewall, storage backend limitations), the server will also reject a file before it actually gets uploaded, the client will handle the error as described above. If a client cannot represent the file name in the filesystem, it will inform about this fact. No download will occur. Test:
- Add a file that cannot be represented on Windows (including a colon (
:) for instance). - Sync the file up, and sync it down it on clients installed on Linux, Mac OS and Linux respective. The up/downsync is expected to succeed on all platforms but Windows.
☁️