Expiration date of a new public link from quick action

[exalate-issue-sync]

A public link that was created with the public link quick action on ocis sets an expiration date to start of today + 0 days, because we don't have a default expiration time span in ocis. In oc10 the default expiry is required to be >= 1 day.

Decision needed:

1. don't set a default expiration date for links from quick actions in ocis (set capabilities.files_sharing.public.expire_date.enabled to false)
2. decide a default expiry for public links (set capabilities.files_sharing.public.expire_date.days to a value which has to be decided first)
3. implement default expiry based on settings and hook it into capabilities.files_sharing.public.expire_date

[exalate-issue-sync]

Benedikt Kulmann commented: Since we don't have expirations for public links at all, we'll hardcode capabilities.files_sharing.public.expire_date.enabled to false.

[exalate-issue-sync]

Alex Unger commented: > Since we don't have expirations for public links at all, we'll hardcode capabilities.files_sharing.public.expire_date.enabled to false.

This statement is no longer true. cs3org/reva#1361 got merged and it addresses time sensitive public shares, so public shares do expire now, and they are removed from the response.

[exalate-issue-sync]

Benedikt Kulmann commented: Awesome! :)
[~pmaier] do we still want public link expiration disabled by default on the quick action for public links? Or do we want to have a hardcoded default expiration span now?

[exalate-issue-sync]

Patrick Maier commented: > Patrick Maier do we still want public link expiration disabled by default on the quick action for public links? Or do we want to have a hardcoded default expiration span now?

Yes, no hardcoded expiration date for quick action links, please.
a) We should not hardcode an arbitrary value for this.
b) Defaults and enforcements for expiration dates are a separate feature we do not have yet.
c) The quick action public links on the desktop client also do not set an expiration date, so we're consistent here.