Transfer Expiration

Purpose

Transfer expiration determines, how long after upload a transfer will stay available on the system.

Details

Person-to-person transfer remain on the system for a certain amount of time (time to live or TTL), until they expire when they will be irreversibly removed. The desired TTL is selected by the sender at time of upload.

Image

Any transfer that is not yet expired can be extended by both sender and receiver.

Image

The available values are filtered:

  1. A cluster-admin defines the set of possible TTL values available to admins.
  2. An administrator selects from this set a number of TTLs that the users of the adminunit can chose from.
  3. The administrator can deny users the possibility to chose the TTL altogether.
  4. The administrator selects the default TTL, which is selected initially as the default, or when users may not chose the TTL themselves.

Configuration

  • Scope: adminunit, applies immediately to all new transfers
  • Privileges:
    • cluster-admins define the allowedExpirationIntervals as per the contract.
    • server admins select the expirationIntervals and default TTL from that.
  • Default: The defaults apply when a new adminunit is created from scratch.
    • User can set exiration interval: disabled
    • allowedExpirationIntervals get loaded from the ENV file chain: $ENV['allowed_expiry_interval_array'] = array(1, 2, 3, 5, 7, 14, 31);
    • default TTL is loaded from ENV: $ENV['expiry_interval'] = 14;
    • expirationIntervals contains only the default TTL

A server administrator can set the TTL values available to the users of the adminunit in the (new) admin interface, section Server Settings, subsection Time To Live:

Image

Note

Cluster-administrators can theoretically set the allowedExpirationIntervals by updating the adminunit via API, but no frontend exists yet.

Dependencies

none

Conflicts

Drive transfers have no expiration time and therefore are not affected by these settings