Admin should _not_ be able to change password when:
- if an encryption module is loaded and it uses per-user keys
- if encryption is enabled but no encryption modules are loaded
Admin should be able to change the password when:
- no encryption module is loaded and encryption is disabled
- encryption module is loaded but it doesn't require per user keys
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
Fixes#7084
Now entering wrongly cased email (roeland@ instead of Roeland@) for
password reset etc. Will also work.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
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>
Each time a new actor appears in a scenario the browser window of the
new actor is put in front of the browser windows of the previous actors.
Before, when acting again as a previous actor his browser window stayed
in the background; in most cases everything worked fine even if the
window was in the background, but due to a bug in the Firefox driver of
Selenium and/or maybe in Firefox itself when the window was in the
background it was not possible to set the value of an input field that
had a range selected.
Now, when acting again as a previous actor his browser window is brought
to the foreground. This prevents the bug from manifesting, but also
reflects better how a user would interact with the browser in real life.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The PHP built-in server can crash when certain actions are performed in
Nextcloud (but although the crash is triggered by Nextcloud it does not
seem to be a Nextcloud bug), which can lead to failures in the
acceptance tests that would have otherwise passed.
A crash of the PHP built-in server during an acceptance test can be
identified by the message "sh: 1: kill: No such process" in the
acceptance tests output; as the PHP built-in server crashed its process
does no longer exist when it is tried to be killed when the scenario
ends.
Although the crash has been observed in other tests too it is more
prevalent in the tests for tags and the theming app. In order to
reduce the false positives those tests are now run on Apache instead of
on the PHP built-in sever. However, the rest of tests are still run on
the PHP built-in server due to its lower resource consumption.
In order to run a feature or just a scenario using Apache it has to be
tagged with "@apache"; features or scenarios without that tag (the
default) will run on the PHP built-in server instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to run the acceptance tests in Apache "/var/www/html" has to be
linked to the root directory of the Nextcloud server. Before this was
automatically done when launching the acceptance tests through
"./run.sh", but an explicit command was needed when run in Drone. Now
the linking was moved from "run.sh" to "run-local.sh", so it is
automatically done when run through "./run.sh" and in Drone, including
when running the tests for an app instead of for the server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In 2f87fb6b45 this header was introduced. The referenced documentation says:
> When delivered with a response from https://example.com/clear, the following header will cause cookies associated with the origin https://example.com to be cleared, as well as cookies on any origin in the same registered domain (e.g. https://www.example.com/ and https://more.subdomains.example.com/).
This also applies if `https://nextcloud.example.com/` sends the `Clear-Site-Data: "cookies"` header.
This is not the behavior we want at this point!
So I removed the deletion of cookies from the header. This has no effect on the logout process as this header is supported only recently and the logout works in old browsers as well.
Signed-off-by: Patrick Conrad <conrad@iza.org>
(cherry picked from commit 1806baaeaf)
Robin Appelman
Roeland Jago Douma
Roeland Jago Douma
Bjoern Schiessle
Daniel Calviño Sánchez
Carsten Wiedmann
Julius Härtl
Daniel Kesselberg
Georg Ehrke
Morris Jobke
Kyle Fazzari
Patrick Conrad