Core concepts（核心概念）¶
Before using Recipes, we recommend learning more about the core concepts that define the creation and use of recipes in Foundry: expiration, run history, and permissions.
Expiration¶
Recipes take computational resources to continue to operate. To ensure that unused recipes do not take up resources, we require recipes to expire. When recipes expire, they are not deleted. Expired recipes simply do not continue monitoring for the condition of interest, which means all recipients of that recipe's notification will no longer be notified. The author will be notified at some intervals before a recipe is set to expire and can choose to extend the expiration at any time if they want it to continue running. If they forget to do so and the recipe expires, they can still choose to resume and extend the recipe.
Learn more about changing recipe expiration.
Run history¶
Based on your schedule, your recipe will run either on a time-based schedule (for example, every 3 hours or every Monday at 9 a.m.) or an event-based schedule (when a dataset updates or when a new object is detected).
Each time the recipe runs, its run history will record one of the following run statuses:
- success with exceptions: The recipe ran successfully and notified all recipients who had access to the resource and did not mute the recipe. This status may occur if some recipients lacked access to the resource and did not receive a notification. In the case of a report recipe, success with exceptions can also occur if exporting the report failed for some recipients and they received a link instead. Learn more about recipe permissions and security below.
- success: The recipe ran successfully and notified everyone who did not mute the recipe.
- skipped: The recipe was successfully triggered but did not send any notifications. This could occur either because all recipients had muted the recipe or because the condition it was checking was not true.
- failed: The recipe did not run successfully and encountered an error while running. More details about this error can be seen by expanding the recipe history for this run.
An author will receive notifications for failures and successes with exceptions. Learn more about configuring your notification preferences.
Privacy, permissions, and sharing¶
Recipes inherit permissions from the resource it monitors. This means that anyone who can view the resource can view the recipe, anyone who owns the resource can edit the recipe, and so on.
While recipes can send data out via email to other users, permissions ensure that only the users that have access to the data will actually receive that data in their email.
Permissions summary¶
Definitions¶
- Author/Owner: The user who created the recipe.
- Recipient: The recipient of the triggered email/notification of the recipe.
- Monitored resource: The actual file the recipe is monitoring for the change of interest (dataset, report, Quiver analysis, etc).
The table below shows the permissions necessary for users to perform certain actions in Recipes:
| Action | Authorized users |
|---|---|
| View the recipe | The author or anyone with `Viewer` access to the monitored resource |
| Modify and manage the recipe | The author or anyone with `Owner` access to the monitored resource |
| Receive emails/notifications from the recipe | Recipients with `Viewer` access on the monitored resource (1.) |
If the recipient does not have access to a report, they will still receive the notification. However, they will receive a link to the report which will direct them to request access.
:::callout{theme="neutral"}
If a user tries to add a recipient to their recipe who does not have access to the underlying resources, the recipient will be able to see the recipe but not the resources. They will receive the email/notification, but they will not be able to open the linked resource, and the email/notification will not contain any attachments. To allow all recipients to receive emails/notifications, make sure they have at least Viewer access to the recipe resources.
:::
中文翻译¶
核心概念¶
在使用配方(Recipe)之前，我们建议您先了解定义配方创建和使用的核心概念：过期(Expiration)、运行历史(Run History)和权限(Permissions)。
过期(Expiration)¶
配方需要持续占用计算资源才能运行。为确保未使用的配方不会占用资源，我们要求配方设置过期时间。配方过期后不会被删除，只是不再继续监控感兴趣的条件，这意味着该配方通知的所有收件人将不再收到通知。在配方即将过期前，系统会按一定间隔通知作者，作者可以随时选择延长过期时间以继续运行。如果作者忘记操作导致配方过期，仍可选择恢复并延长配方。
了解更多关于更改配方过期时间的信息。
运行历史(Run history)¶
根据您设定的计划，配方将按时间计划（例如每3小时一次或每周一上午9点）或事件计划（当数据集更新或检测到新对象时）运行。
每次配方运行时，其运行历史将记录以下运行状态之一：
- 成功但有异常(success with exceptions)： 配方成功运行，并通知了所有有权访问资源且未静默配方的收件人。如果某些收件人无权访问资源而未收到通知，则可能出现此状态。对于报告配方，如果某些收件人导出报告失败而收到链接，也可能出现成功但有异常的情况。了解更多关于配方权限和安全的信息，请参见下文。
- 成功(success)： 配方成功运行，并通知了所有未静默配方的用户。
- 已跳过(skipped)： 配方成功触发但未发送任何通知。这可能是因为所有收件人都已静默配方，或者配方检查的条件不成立。
- 失败(failed)： 配方未成功运行，在运行过程中遇到错误。展开本次运行的配方历史可查看错误的详细信息。
作者将收到失败和成功但有异常的通知。了解更多关于配置通知偏好的信息。
隐私、权限与共享(Privacy, permissions, and sharing)¶
配方继承自其所监控资源的权限。这意味着任何可以查看该资源的用户都可以查看配方，任何拥有该资源的用户都可以编辑配方，依此类推。
虽然配方可以通过电子邮件将数据发送给其他用户，但权限机制确保只有拥有数据访问权限的用户才能在其电子邮件中实际收到这些数据。
权限摘要¶
定义¶
- 作者/所有者(Author/Owner)： 创建配方的用户。
- 收件人(Recipient)： 接收配方触发的电子邮件/通知的用户。
- 被监控资源(Monitored resource)： 配方正在监控其变化的实际文件（数据集、报告、Quiver分析等）。
下表显示了用户在配方中执行某些操作所需的权限：
| 操作 | 授权用户 |
|---|---|
| 查看配方 | 作者或任何对被监控资源拥有`查看者(Viewer)`权限的用户 |
| 修改和管理配方 | 作者或任何对被监控资源拥有`所有者(Owner)`权限的用户 |
| 接收配方的电子邮件/通知 | 对被监控资源拥有`查看者(Viewer)`权限的收件人 (1.) |
如果收件人无权访问报告，他们仍会收到通知，但通知中将包含一个指向报告的链接，引导他们申请访问权限。
:::callout{theme="neutral"}
如果用户尝试将无权访问底层资源的收件人添加到配方中，该收件人将能看到配方但无法查看资源。他们会收到电子邮件/通知，但无法打开链接的资源，且电子邮件/通知中不会包含任何附件。为确保所有收件人都能收到电子邮件/通知，请确保他们对配方资源至少拥有查看者(Viewer)权限。
:::