If the server is too slow, changing to a different file immediately
after sending a new comment but without waiting for the comment to be
shown for the original file could cause the new comment to be shown for
the current file instead.
This is, indeed, a bug in the comments. However, it is not possible to
test it reliably in the acceptance tests, as it depends on how fast the
server adds the message and how fast the client changes to a different
file; sometimes the test would fail and sometimes it would not.
Therefore, now it is waited for the comment to be added before changing
to another file, as in this case it can be reliably tested that changing
to a different file does not cause the comments from the previous file
to be shown in the current file (this was a different bug already fixed
and due to which this test was added in the first place).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "Comments" tab is open the empty content element is always in
the DOM, although it is only shown once the message collection was
fetched and there were no messages. Due to this it is necessary to
explicitly wait for it to be shown instead of relying on the implicit
wait made to find the element; otherwise it would be found immediately
and if the collection was not fetched yet it would not be visible,
causing the test to fail.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Having both "FilesAppSharingContext" and "FilesSharingAppContext" was
confusing, so "FilesSharingAppContext" was renamed to a more descriptive
name.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To reshare a file there must be at least three enabled users in the
system; although it would be possible to run the steps to create a third
user in the scenarios that need it for convenience a third enabled user
besides "admin" and "user0" was added to the default setup.
In a similar way, a new step was added too to login as a given user
name, similar to the steps to log in as "user0" and as "admin".
Finally, another actor, "Jim", was introduced for those scenarios which
should be played by three standard actors (that is, without a special
configuration like "Rubeus").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "Download" item in the menu of public share pages is no longer shown
in wide (>768px) windows (although the element is in the DOM and shown
if resized to a narrow window).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the acceptance tests the link share menu is automatically opened if
needed before interacting with an item in the menu; if the menu is not
open it is opened by clicking on its toggle.
However, since a recent change the link share menu is automatically
opened by the regular UI after the link share is created. This causes
that, sometimes, after the creation of a link share the acceptance tests
check whether the menu is shown or not before the menu was automatically
opened; as the menu is not open then the acceptance tests proceed to
click on the toggle, but in the meantime the link share was created and
the menu opened, so clicking on the toggle now closes it. As the menu is
closed it is not possible to interact with its items and the test fails.
To prevent that now the acceptance tests wait for the link share menu to
open after a link share is created before continuing with the other
steps.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the sendmail binary can't be found at all we fallback to the default
path.
It most likely is not there but then at least a proper error message
pops up.
Updated the tests to also properly pass.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The update share tests only checked that the share returned by
"update()" had the expected values. However, as "update()" returns the
same share that was given as a parameter the tests were not really
verifying that the values were updated in the database.
In a similar way, the test that checked that a password was removed did
not set a password first, so even if the database returned null it could
be simply returning the default value for the share; a password must be
set first to ensure that it is removed.
Besides that, a typo was fixed too that made the checks on the original
share instead of on the one returned by "update()"; right now it is the
same share, so the change makes no difference, but it is how the check
should be done anyway.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Although now it is possible to create several link shares the acceptance
tests currently handles only the first link share; this first link share
is now created by clicking an "Add new share" button instead of a
checkbox.
Besides that, the "Copy link" button has been moved from the menu to the
row, next to the menu trigger.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If a user can't authenticate normally (because they have 2FA that is not
available on their devices for example). The redirect that is generated
should be of the proper format.
This means
1. Include the protocol
2. Include the possible subfolder
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
this removes the need for temporary storages with some external storage backends.
The new method is added to a separate interface to maintain compatibility with
storage backends implementing the storage interface directly (without inheriting common)
Currently the interface is implemented for objectstorage based storages and local storage
and used by webdav uploads
Signed-off-by: Robin Appelman <robin@icewind.nl>
Before we'd round up all preview request to their nearest power of two.
This resulted still in a lot of possible images. Generating a lot of
server load and taking up a lot of space.
This moves it to previews to be powers of 4: 64, 256, 1024 and 4096
Also the first two powers are always skipped (4, 16) as it doesn't make
sense to generate previews for that.
We cache preview pretty agressively and I feel this is a better
tradeoff.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>