Configuring the Packages Application

Using the AoC Packages application, a user can complete three primary actions. These actions take place in the context of a workspace.

• Send files and folders to others or to a shared inbox.
• Request others to send files and folders.
• Request others to send files and folders to a shared inbox.

When users select files and folders to exchange, Aspera on Cloud collects them into a digital package.

Sending Files and Folders to Others

Packages app users can select files and folders to send from any connected source: the local machine, a remote host, cloud storage, etc. Using an email-like interface, the user addresses recipients and selects the intended content. AoC collects copies of the content into a digital package and sends the package to the recipients. The package contains a snapshot of the selected content at the time of package creation. For a user procedure, see Sending Files and Folders

Requesting Others to Send Files and Folders

Packages app members can send a submission link to invite another person to compose and send a digital package to them. Packages app users can request a package be sent either to them as an individual or to a shared inbox of which they are a member with Add users permission.

Aspera on Cloud delivers the invitation as an email to the recipient. The email contains the submission link, which allows the recipient to use Aspera technology to compose and send digital packages, even if they do not have an AoC account.

For a user procedure, see Inviting Others to Send Content.

You can configure settings that determine how members of the Packages application can use Packages app features.

As an organization administrator, you can:

• Configure global, organization-wide Packages app settings that are inherited as defaults in all workspaces.
• In a given workspace, override inherited global settings. Workspace settings are inherited as defaults by all shared inboxes in that workspace.
• In a given shared inbox, override certain settings inherited from the workspace.
• Delegate workspace and shared-inbox settings to a workspace manager.

All workspaces in your organization inherit the settings you configure for the Packages app at the global level. If desired, you can customize these inherited settings for a given workspace.

Configure which workspace member types can use submission links to request packages. When you allow members or managers to send submission links, you can specify to whom they can send them.

If the Packages app is enabled both globally and for a given workspace, all members of that workspace can send packages to fellow workspace members. This is a fundamental function and cannot be changed.

By default, all such workspace members can send packages to organization members in other workspaces, or to people outside the organization. However, you can limit that capability.

External recipients (also called outside recipients) are not members of the given workspace. They may or may not have membership in a different workspace, or they may not be a member of the AoC org at all.

By default, external or outside recipients can receive and access packages without creating an Aspera on Cloud account and signing in. This allows workspace members to send packages to external users without those users becoming Aspera on Cloud members and being added to the Aspera on Cloud user database.

If you check the box labeled Require external users to log in when receiving packages, external recipients must create an Aspera on Cloud account and sign in to access the packages sent. These external recipients thereby become Limited members of the workspace.

For more information about Limited users, see User Roles and Types.

By default, all members of a workspace can send a package to the entire workspace by entering the workspace name as a recipient in the To field of the Send files form. To reduce the risk of a workspace member unintentionally sending sensitive content workspace-wide, you can restrict this capability to workspace managers only. You can also prevent all members and managers from sending to the entire workspace in this way.

When you configure this restriction, the To field in the Send files form does not accept the workspace name as a valid entry. Note that users can, however, work around this restriction by entering every workspace member name in the To field.

To configure this restriction, do the following:

Members of the Aspera on Cloud Packages application send URL links to request files and folders from others.

Aspera on Cloud sends the recipient an email notification containing a link that opens a portal interface that allows the recipient to compose and send a digital package.

The administrator can configure the style of URL that Aspera on Cloud generates for file request operations. There are three URL styles available:

• Standard URLs
  • Select Standard to generate full-length URLs.
  • Example of standard URL: https://aspera.ibmaspera.com/public/send?token=HBf-sfRFIHFMUXuYdocSi22X8pYRk_E8OxXOi4IOOWs
• Short URLs
  • Short URLs are enabled by default for a workspace.
  • Example of short URL: https://aspera.pub/2dexfa
• Personalized URLs
  • When you select Personalized, Aspera on Cloud uses a default that includes the sender's username, or, for a shared inbox, the shared inbox name.
    • Example of default personalized URL for a user: https://aspera.pub/2dexfa/Jane_Doe
    • Example of default personalized URL for a shared inbox named "Captions": https://aspera.pub/2dexfa/Captions
  • When you select Personalized, users can customize the default URL and compose a string of up to 240 characters. All characters beyond the conventional alphanumeric set (A through Z; a through z; 0 through 9) are replaced with underscore characters.
  • Example of customized personalized URL: https://aspera.pub/2dax/My_Own_Personal_Link

For increased security and traceability, you can require external users of the AoC submission portal to include their name and email with the package they submit. If you do not select the option to require this information, the submission portal user has the option to include this information, but can successfully submit a package without including it. If the external submitter does not include this information, the package displays in the recipient's inbox with the sender identified only as "Anonymous sender".

To require that submission portal users include their name and email with their submission, do the following.

You can configure an organization-level setting requiring that all packages sent in the organization automatically have encryption at rest (EAR) applied. Sending with EAR applied ensures that package contents remain encrypted at the receiving end, even after the recipient downloads the files and folders in the packages.

Senders must enter and confirm a passphrase for every package they send with EAR applied, then must deliver the passphrase to the recipient according to local site security practices. The recipient must apply that passphrase to decrypt the downloaded package.

Every workspace inherits the organization setting, but the administrator can override the inherited setting and either apply or remove EAR for packages sent in the workspace.

When you require EAR at the workspace, senders cannot send a package without EAR. However, even if you do not require EAR at the workspace, senders have the option to apply EAR to individual packages.

By default, package senders and recipients can see the download counters in the details panel of each package (in the Packages app, click the package row to display the details panel, then click More detail); when these users hover over the counters ('Downloads' and 'Partial downloads'), AoC displays the names of recipients who have downloaded the package.

When you deselect the check box labeled Show download count within package details, neither senders nor recipients can see the download counters, and so have no visibility regarding package downloads.

You can configure optional content expiration policies that apply to digital packages in your organization. As always, you can override the organization-level settings for a given workspace. In the case of package expiration settings, you can also customize settings for each shared inbox.

• Time-based content expiration: This setting determines how long Aspera on Cloud maintains contents of a package. For example, if you configure this setting for 10 days, Aspera on Cloud deletes package contents 10 days after the package becomes available to the intended recipients. You can apply a separate time-based expiration policy to recalled packages in the workspace.
  Note: Content expiration also applies to packages in failed transfers.
• Download-based content expiration: This setting determines whether Aspera on Cloud deletes package contents after either:
  • All recipients have downloaded the package.
  • Any one recipient has downloaded the package
  In this context, downloaded means either downloaded the entire package (Download all) or downloaded all the individual contents of the package in one operation. Downloading only some of the package contents does not meet the expiration threshold.

  For a shared inbox, you can set this download-based policy to archive rather than delete an expired package. See Configuring Shared Inbox Settings.

  Note: If you configure both policy types for a workspace or shared inbox, Aspera on Cloud deletes packages according to the policy that applies soonest.
  Note: Package deletion is a scheduled background job. There can be a delay of up to an hour between the download-based expiration threshold being crossed and actual package deletion.

You can configure a given workspace to generate a JSON 'sidecar' file to be included in each package sent from the workspace. This JSON file appears in the package very shortly after the transfer completes; it contains transfer statistics like package size and average transfer rate, and package details like sender, recipients, contents, user-configured metadata, and more.

To configure this feature, do the following:

You can enable all members of a given workspace to have access to all packages sent by all workspace members. This access enhances collaboration among workspace members.

To enable this capability, select the check box labeled Make all sent packages accessible to all workspace members. When you deselect this check box, members of this workspace can see and access only the sent packages they themselves sent.

Among other benefits, this access allows teammates within a workspace to add recipients to a package already sent by another workspace member.

Adding Recipients to a Package Compared to Forwarding a Package

To read the related user documentation, see Adding Recipients to a Sent Package.

Procedure

To enable this feature, do the following: