Public link share expiry interaction with core

[phil-davis]

The password policy public link expiration settings can conflict with core settings, e.g. link expiry set to 5 days in password policy:

Link expiry set to 7 days in core:

Create a public link:

core fills in the default expiry date, then when you click "Share" to create the link, password policy in the backend complains that "The expiration date cannot exceed 5 days."

This problem is "just a nuisance" - the user can adjust the expiration date earlier and the link gets created.

See #286 (comment) - this is existing "annoying" behaviour with core 10.3.2

[phil-davis]

Now do not enable "set default expiration date" in core:

And when you try to make a public link you get:

Then you use the date picker and choose a date. The date picker gives you no clue what the maximum expiry is. You choose some date in the future, then:

Finally you get told "The expiration date cannot exceed 5 days." At this point you have enough clues to choose a valid expiration date.

It would be nice if it filled in the maximum from the password policy setting at the start.

[phil-davis]

Someone remind me - what is the real point of the settings in password policy vs core?

In password policy you can set different maximum expiration depending if a password is set on the public link share or not. Is that the only extra functionality that is available?

[pako81]

#286 (comment) caused by a missing check for the share type (public link) here https://github.com/owncloud/password_policy/blob/master/lib/HooksHandler.php#L201.

So the proposed fix would need to add two additional checks: one at the above-mentioned place, the other one at https://github.com/owncloud/password_policy/blob/master/lib/HooksHandler.php#L195, which will solve #287.

So one fix for two issues: 1. fix creation of ordinary shares when public link expiry is set and 2. fix conflicts between core and password_policy expiration policies.

[pako81]

In password policy you can set different maximum expiration depending if a password is set on the public link share or not. Is that the only extra functionality that is available?

Yes, it is. IMHO we should just get rid of the core settings since this is introducing redundancy.

[phil-davis]

Yes, it is. IMHO we should just get rid of the core settings since this is introducing redundancy.

The core settings let you specify a default expiration date without enforcing it (and you can enforce it if you want)

Maybe define a combined set of requirements for the feature, then decide if the combined requirements are implemented in core (and remove existing link expiration settings from password policy) or the reverse.

[phil-davis]

I tested the above with core 10.3.2 - the "annoying" behaviour is the same.
So this is not a regression in core 10.4.0.

IMO the "annoyance" can be improved in some future software version (of core and/or password_policy, wherever the code needs to be enhanced). That work can scheduled as normal.

[VicDeo]

In password policy you can set different maximum expiration depending if a password is set on the public link share or not. Is that the only extra functionality that is available?
Yes, it is. IMHO we should just get rid of the core settings since this is introducing redundancy.

I think reusing of the core setting in the app is better approach.