-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Respect empty expiryDate
value in server
#44485
Conversation
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! |
Related changes : #44912 |
be0e0fc
to
dbb802a
Compare
expiryDate
value in serverexpiryDate
value in server
/backport to stable29 |
/backport to stable28 |
/backport to stable27 |
@@ -487,25 +417,6 @@ protected function validateExpirationDateLink(IShare $share) { | |||
} | |||
} | |||
|
|||
// If expiredate is empty set a default one if there is a default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but you are removing the default functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes :)... Since the users now have the opportunity to modify this settings before a share is created. i.e
the user can see on the share creation menu, that an expiry date is required and can either allow the default or remove if not enforced.
Leaving this default functionality means, we always force shares to have expiry dates even when that's not the users intention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that currently existing clients and app might rely on the default and not populate it via the UI or send it with each request.
So this is a breaking change that is impossible to discover and will lead to a lot of shares not expiring although they should.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. This breaking change is inevitable if we would solve #44219 though.
I am not sure but perhaps I could introduce checks for clients/app calls.
Another though is that Manager
class is only part of the private API and maybe all we need to do is make sure the apps we maintain that uses the non public share interface are updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another though is that Manager class is only part of the private API and maybe all we need to do is make sure the apps we maintain that uses the non public share interface are updated?
I meant apps like Android, iOS and our Desktop Client:
string $expireDate = '', server/apps/files_sharing/lib/Controller/ShareAPIController.php
Lines 648 to 656 in 490f545
//Expire date if ($expireDate !== '') { try { $expireDateTime = $this->parseDate($expireDate); $share->setExpirationDate($expireDateTime); } catch (\Exception $e) { throw new OCSNotFoundException($this->l->t('Invalid date, date format must be YYYY-MM-DD')); } }
That being said, the update also supports it, but basically you need to set it to ''
(empty string) not null when updating a share and removing a expiration date.
Seems to work when updating, just not when creating, as the check is always executed then.
So instead of tampering with validateExpirationDateInternal
like this, I would try to get the information into the share object that no expirationDate was sent and in
server/lib/private/Share20/Manager.php
Line 423 in ec5133b
if ($fullId === null && $expirationDate === null && $defaultExpireDate) { |
$expirationDate === null
you also check whether it was sent with the empty string, and only set the default date when it was not sent as empty string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nickvergessen resorted to something similar, makes plenty of sense.
9effd09
to
e6a6340
Compare
30e59ba
to
a47d7b0
Compare
2a233b1
to
8dd6554
Compare
If `expireDate` is an empty string and not `null` then the server should not set a default. Signed-off-by: fenn-cs <[email protected]>
Signed-off-by: fenn-cs <[email protected]>
- Verify that explicitly sending empty `expireDate` param to server overwrite default and sets not expiry date, if non is enforced. - Update tests to avoid converting empty string to date. Signed-off-by: fenn-cs <[email protected]>
8dd6554
to
d41d885
Compare
This breaks uploading in Talk which expects |
Also on 27? |
If
expireDate
is an empty string and notnull
then the server should not set a default.Resolves : #44219