Skip to content
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

set default expiration date if expiration date is enforced and it is new share #35564

Merged
merged 1 commit into from
Jun 19, 2019

Conversation

karakayasemi
Copy link
Contributor

Description

Automatic expiration date setting behavior changed with #34971. It caused regression on client sides. This PR fixes this regression by keeping #34971's functionality.

If max expiration date is enforced set default expiration date for new share. @ckamm please check the behavior is same as expected or not.

@micbar @pmaier1 we should consider this PR for v10.2.1.

Related Issue

Motivation and Context

Automatic expiration date setting behavior changed with #34971. It caused regression on client sides. This PR fixes this regression by keeping #34971's functionality.

How Has This Been Tested?.

To test issue #35550

  • Activate, "Set expiration date" and enforce max expiration date.
  • Try to create new public link from a desktop client
  • It should create link and fill expiration date with default.

To test issue #34960

  • Activate, "Set expiration date" but not enforce.
  • Click share a file via public link and remove default expiration date from its input field. The share should be created without an expiration date.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Database schema changes (next release will require increase of minor version instead of patch)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Technical debt
  • Tests only (no source changes)

Checklist:

  • Code changes
  • Unit tests added
  • Acceptance tests added
  • Documentation ticket raised:

Open tasks:

  • Backport (if applicable set "backport-request" label and remove when the backport was done)

@micbar
Copy link
Contributor

micbar commented Jun 17, 2019

@karakayasemi Great!
Please force push, random CI failure

@codecov
Copy link

codecov bot commented Jun 17, 2019

Codecov Report

Merging #35564 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #35564      +/-   ##
============================================
+ Coverage     65.66%   65.67%   +<.01%     
- Complexity    18757    18761       +4     
============================================
  Files          1222     1222              
  Lines         70873    70880       +7     
  Branches       1289     1289              
============================================
+ Hits          46541    46548       +7     
  Misses        23954    23954              
  Partials        378      378
Flag Coverage Δ Complexity Δ
#javascript 53.7% <ø> (ø) 0 <ø> (ø) ⬇️
#phpunit 67.04% <100%> (ø) 18761 <0> (+4) ⬆️
Impacted Files Coverage Δ Complexity Δ
lib/private/Share20/Manager.php 97.46% <100%> (+0.02%) 234 <0> (+4) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 038c731...f050db6. Read the comment docs.

@codecov
Copy link

codecov bot commented Jun 17, 2019

Codecov Report

Merging #35564 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #35564      +/-   ##
============================================
+ Coverage     65.66%   65.67%   +<.01%     
- Complexity    18757    18762       +5     
============================================
  Files          1222     1222              
  Lines         70873    70882       +9     
  Branches       1289     1289              
============================================
+ Hits          46541    46550       +9     
  Misses        23954    23954              
  Partials        378      378
Flag Coverage Δ Complexity Δ
#javascript 53.7% <ø> (ø) 0 <ø> (ø) ⬇️
#phpunit 67.04% <100%> (ø) 18762 <2> (+5) ⬆️
Impacted Files Coverage Δ Complexity Δ
lib/private/Share20/Manager.php 97.47% <100%> (+0.03%) 235 <2> (+5) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a933d9...eb0446f. Read the comment docs.

@jvillafanez
Copy link
Member

It feels better if this is added in the createShare method unless this is also somehow applied when a user updates the share.

@karakayasemi
Copy link
Contributor Author

It feels better if this is added in the createShare method unless this is also somehow applied when a user updates the share.

Both createShare and updateShare method are using validateExpirationDate method.
If expirationDate null, for a new share validateExpirationDate method sets default date with this PR (expected behavior for clients), but for an update case, it throws InvalidArgumentException.

@ckamm
Copy link

ckamm commented Jun 18, 2019

@karakayasemi Excellent, I'll test it now.

@ckamm
Copy link

ckamm commented Jun 18, 2019

Tests:

  1. Default + enforced expiration date
  • Web: Expiration date is pre-filled. Removing it leads to error. (good)
  • Desktop 2.6: Expiration date is pre-filled. Removing is impossible. (good)
  • Desktop 2.5: Creating share works, has expiration date. Removing is impossible. (good)
  1. Default, but not enforced expiration date
  • Web: Expiration date is pre-filled. Removing it before creation leads to share with expiration. (bug)
  • Desktop 2.6: Expiration date is not pre-checked (client side bug). Removing it before creation leads to share with expiration. (bug)
  • Desktop 2.5: Creating share works, has expiration date. Can be removed. (good)

What's the API for "create share without expiration" vs "create share with default expiration"?

Copy link

@ckamm ckamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test issues, see comment

@karakayasemi
Copy link
Contributor Author

@ckamm thanks for detailed explanation. I moved the code-block which set expiration date inside if($this->shareApiLinkDefaultExpireDateEnforced()) condition.
I tested scenarios with webUI and client 2.5.4, everything seems okay this time. Please you also test one more time. Thanks.

What's the API for "create share without expiration" vs "create share with default expiration"?

They both uses same OCS API and following same code flow, no difference between them.

@karakayasemi karakayasemi requested a review from ckamm June 18, 2019 08:30
@@ -331,6 +331,20 @@ protected function validateExpirationDate(\OCP\Share\IShare $share) {

// If we enforce the expiration date check that is does not exceed
if ($this->shareApiLinkDefaultExpireDateEnforced()) {
// If expiredate is empty set a default one if there is a default
$fullId = null;
try {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better if this check is moved to a private function isNewShare or similar.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jvillafanez moved to a new function. Thanks.

@ckamm
Copy link

ckamm commented Jun 18, 2019

Retested this case:
2) Default, but not enforced expiration date

  • Web: Expiration date is pre-filled. Removing it before creation leads to share without expiration. (good)
  • Desktop 2.6: Expiration date is not pre-checked (client side bug). Removing it before creation leads to share without expiration. (good)
  • Desktop 2.5: Creating share works, but has no expiration date. Can be added later. (bug)

There's still a regression with older clients that expect the server to add the default expiration date even if it's not required. But that's much less severe than not being able to create shares, so I'm fine with including this already.

I'm pretty sure one can only get everything right by keeping the old "null means default" behavior intact and making the new "request share without expiration" have different API.

@jvillafanez
Copy link
Member

code looks fine, so if it behaves fine I think it's good to merge

@patrickjahns
Copy link
Contributor

I'm pretty sure one can only get everything right by keeping the old "null means default" behavior intact and making the new "request share without expiration" have different API.

Thanks for highlighting this - was this change introduced in 10.2.0 or before?

@phil-davis
Copy link
Contributor

Backports
stable10 #35592
release-10.2.1 #35593

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Public link share creation no longer automatically sets expiration date
6 participants