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>
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>
Daniel Calviño Sánchez
Robin Appelman
Christoph Wurst
Morris Jobke
Roeland Jago Douma
Joas Schilling
Julius Härtl
Roeland Jago Douma