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>
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>
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>
