Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions transfer_examples/move/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,13 @@ The entire directory's contents, including files and subdirectories, will be cop
====
This example differs from the
link:https://app.globus.org/flows/f37e5766-7b3c-4c02-92ee-e6aacd8f4cb8/definition[Move (copy and delete) files^]
Globus-provided Flow available in the Globus Web App.
Globus-provided **flow** available in the Globus Web App.

The example is simplified and may exhibit slightly different behaviors.
====

== Highlights

In the example definition, the `IdentifyPathTypes` state uses expression evaluators to prepare several boolean values.
In the example definition, the `IdentifyPathTypes` **state** uses expression evaluators to prepare several boolean values.

These boolean values are used by the `TestPathConstraints` state to conditionally modify the destination path used by the `Transfer` state.
These boolean values are used by the `TestPathConstraints` **state** to conditionally modify the destination path used by the `Transfer` **state**.
39 changes: 20 additions & 19 deletions transfer_examples/transfer_after_approval/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@
Allow users to submit an approval request to transfer a file to a destination Guest Collection.

The request will come in the form of emails to curators who are authorized to approve the transfer.
If approved, the file will be transferred using the flow's own identity -- not the user's --
ensuring that users do not need permission to read or write to the destination collection.
If approved, the file will be transferred using the **flow**'s own identity -- not the user's --
ensuring that users do not need permission to read or write to the destination **collection**.

Users who run the flow will not be informed who the curators/approvers are,
nor will they be informed by the flow itself where the file is transferred to.
They only need to know that "this flow allows you to submit a file for transfer."
Users who run the **flow** will not be informed who the curators/approvers are,
nor will they be informed by the **flow** itself where the file is transferred to.
They only need to know that "this **flow** allows you to submit a file for transfer."

Example uses include:

Expand All @@ -23,46 +23,47 @@ This flow has several technical highlights.

* `__Private_Parameters` and `_private` parameter prefixes are used throughout.
This helps restrict visibility of private information (such as email addresses and SMTP credentials)
when users view the flow definition as well as while the flow runs.
when users view the **flow** definition as well as while their **runs** of the
**flow** are executing.
+
For more information, see link:https://docs.globus.org/api/flows/authoring-flows/secrets/[Protecting Secrets]
in the Authoring Flows documentation.

* By setting the `RunAs` value in the `TransferFile` state,
the transfer operation will be performed using the flow's own identity
* By setting the `RunAs` value in the `TransferFile` **state**,
the transfer operation will be performed using the **flow**'s own identity
to access the destination collection.
This allows the flow to be made public -- and run by any user --
without having to give individual users write permission on the destination collection.
This allows the **flow** to be made public -- and run by any user --
without having to give individual users write permission on the destination **collection**.

== Prerequisites

The flow definition must be modified before using it to create a new flow.
The **flow** definition must be modified before using it to create a new **flow**.
It also has several requirements when running.

=== Modification requirements

* The `SetupEmailLoop` state must be modified.
* The `SetupEmailLoop` **state** must be modified.
The email addresses of approvers must be updated, and unique IDs must be assigned to each reviewer.
Finally, the `loop_end` value must be updated to match the number of approvers.

* The `SendEmail` state must be modified.
* The `SendEmail` **state** must be modified.
Specifically, the SMTP hostname, username, and password in `send_credentials` must be updated,
as well as the email address in `sender`.
+
It is also possible to use an AWS SES credential for sending emails.
See link:https://docs.globus.org/api/flows/hosted-action-providers/ap-notification-notify/[the Notification action provider documentation] for more details.

* The `TransferFile` state must be modified.
* The `TransferFile` **state** must be modified.
The `destination_endpoint` must be set to the destination Guest Collection ID that will receive approved files,
and the `destination_path` should match the target directory you want approved files transferred to.

=== Execution requirements

* After modifying the flow definition and creating the flow in the Globus Flows service,
* After modifying the **flow** definition and creating the **flow** in the Globus Flows service,
a destination collection administrator must give the flow client write permission on the collection.
+
This can be accomplished in the Web App, in the destination collection's Permissions tab,
by clicking the "Add Permissions" button and searching for the flow ID as the username to share with,
This can be accomplished in the Web App, in the destination **collection**'s Permissions tab,
by clicking the "Add Permissions" button and searching for the **flow** ID as the username to share with,
and ensuring that the "Write" checkbox is checked.
+
It's also possible to use the Globus CLI to accomplish this,
Expand All @@ -76,5 +77,5 @@ globus endpoint permission create $DESTINATION_COLLECTION_ID:/ --permissions rw
* Users who seek approval to transfer a file must select a file on a Guest Collection
on which they can grant new permissions.

These execution requirements allow the flow -- _acting as the user_ -- to give itself read permission on the user's guest collection,
and then -- _acting as the flow itself_ -- to transfer the user's file to the destination collection.
These execution requirements allow the **flow** -- _acting as the user_ -- to give itself read permission on the user's Guest Collection,
and then -- _acting as the **flow** itself_ -- to transfer the user's file to the destination **collection**.
6 changes: 3 additions & 3 deletions transfer_examples/two_hop/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,13 @@ Remove from intermediate after completion.
====
This example differs from the
link:https://app.globus.org/flows/99791f7d-6c2c-4675-af4b-b927db68bad0/definition[Two Stage Globus Transfer^]
Globus-provided Flow available in the Globus Web App.
Globus-provided **flow** available in the Globus Web App.

The example below is simplified and may exhibit slightly different behaviors.
====

== Highlights

The `ComputeTaskData` state uses the run ID to create a unique temporary directory on the intermediary endpoint.
The `ComputeTaskData` **state** uses the **run** ID to create a unique temporary directory on the intermediate **collection**.

This helps ensure that existing data on the intermediary endpoint are not overwritten by accident.
This helps ensure that existing data on the intermediate **collection** are not overwritten by accident.