Updating a user or group share now uses the correct method for the
validation of the expiration date. Instead of using the one from links
it uses the one for internal shares.
To avoid future confusion, the method "validateExpirationDate" has been
renamed to "validateExpirationDateLink".
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
This shows in a clearer way that the expected expiration date is the
original one, but without time.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This adds back what was being actually tested in the unit test fixed in
the previous commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The expiration date was explicitly given, so it was not testing what it
should. Moreover, "link_defaultExpDays" needs to be mapped when testing
the default value (even if it will just fallback to the value of
"shareapi_expire_after_n_days").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The enforced expiration date was not actually enabled, as for that
"shareapi_default_expire_date" needs to be explicitly set to "yes".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The test should fail if no exception was thrown, and no exception was
thrown due to a missing configuration parameter. However, the use of
"addToAssertionCount(1)" made the test pass even if no exception was
thrown and, therefore, to silently fail.
Now the missing configuration parameter was added and the test will fail
if the expected exception is not thrown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If we use the owners mount point this results in null. And then the rest
of the checks get called with null. Which doesn't work.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When "send password by Talk" was disabled in a mail share it was
possible to keep the same password as before, as it does not pose any
security issue (unlike keeping it when "send password by Talk" is
enabled, as in that case the password was already disclosed by mail).
However, if a mail share is updated but the password is not set again
only the hashed password will be available. In that case it would not
make sense to send the password by mail, so now the password must be
changed when disabling "send password by Talk".
Note that, even if explicitly setting the same password again along with
the "send password by Talk" property would work, this was also prevented
for simplicity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When "send password by Talk" is enabled in a mail share a new password
must be also set. However, when the passwords of the original and the
new share were compared it was not taken into account that the original
password is now hashed, while the new one is not (unless no new password
was sent, in which case the password of the original share was set in
the new share by the controller, but that was already prevented due to
both passwords being literally the same), so it was possible to set the
same password again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When "send password by Talk" is enabled in a link share now a non empty
password is enforced.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Since federated shares have their permissions set on the node, we do not need
to check for parent share permissions. Otherwise reshares of incoming federated
have no permission variable defined and creating them will fail
Signed-off-by: Julius Härtl <jus@bitgrid.net>