---
title: Permissions and Security
description: "Who can do what, and the checks standing behind each surface. --- ## The Management Capability ``` recurring_form_submissions_manage_resubmissions ``` This single capability governs **every** operational surface: | Surface | Requires it | | --- | --- | | Queue —…"
url: "https://brightleafdigital.io/docs/permissions-and-security/"
updated: "2026-10-18"
category: "Recurring Form Submissions for Gravity Forms / Explanations & Concepts"
---

# Permissions and Security

Who can do what, and the checks standing behind each surface.

---

## The Management Capability

```
recurring_form_submissions_manage_resubmissions
```

This single capability governs **every** operational surface:

| Surface | Requires it |
| --- | --- |
| Queue — viewing and acting | ✅ |
| Entry cards — viewing and acting | ✅ |
| `[rfsfgf_overview]` — the whole table | ✅ |
| `[rfsfgf_entry_widget]` — the whole widget | ✅ |
| The AJAX and admin-post handlers behind every button | ✅ |

Administrators receive it automatically. To grant it to another role, add it with your role editor of choice.

Without it, Queue reports that you don't have permission, and the shortcodes render **nothing at all**.

---

## Settings vs. Operations

Two different permissions, on purpose:

| To… | You need |
| --- | --- |
| Save global settings, or edit a feed | The Gravity Forms settings capability, evaluated through the add-on framework |
| Run, retry, pause, resume, cancel, change a date | `recurring_form_submissions_manage_resubmissions` |

Because the settings check is framework-aware, administrators whose Gravity Forms access comes through the full-access capability can save settings correctly.

---

## Request-Level Checks

Every operational request verifies, in order:

1. **The capability.**
2. **The nonce.**
3. **That the parent entry, form and feed genuinely belong together.**

Point 3 matters: you cannot operate feed 9's schedule through entry 400's form by editing a request, even holding the capability.

Rejections are logged — an expired page token or insufficient permission leaves a record in the add-on log, so a button that appears to do nothing is still traceable.

---

## The Shortcodes

Both shortcodes are **administrative views placed on a front-end page**, not public displays.

- The capability check happens **before anything is rendered**.
- A user without it gets empty output, not a read-only variant.
- Neither shortcode adds a new schedule-management endpoint: operational requests use the same capability-checked and nonce-checked handler as the dashboard.

> Page-level access control is still worth applying. It is simply no longer the only thing standing between a visitor and your series data.

### Widening the read

`rfsfgf_shortcode_can_view` filters the decision before rendering, receiving the capability result, the context (`overview` or `entry_widget`), and for the entry widget an array with the `entry` and `form`.

**Widening the read does not widen the write.** The buttons and the handler behind them still require the management capability.

Scope any widening to the entries a user should see — see *Shortcodes* for a worked example.

---

## Data Minimisation

The plugin's records are built to be shareable:

| Recorded | Never recorded |
| --- | --- |
| Field **IDs** that failed validation | The values in them |
| Exception **class and code** | Exception messages |
| Populate Anything field IDs, dependency presence, result **counts** | Lookup results |
| Timestamps, outcomes, child entry IDs | Submitted payloads |

**Copy Diagnostics** and the **add-on log** pass through the same redaction, which is why both can be sent to support without review.

> Building an extension on the hooks? Follow the same rule: **do not log field values or full entry data.**

---

## What Child Entries Inherit

A child entry is created through normal Gravity Forms processing, so:

- your notifications, feeds and workflows fire as they would for a human submission,
- entry-level permissions and visibility behave as Gravity Forms defines them,
- nothing about the recurring feed relaxes a form's own validation.

If a form must not create entries under some condition, enforce it with **form validation** or the feed's per-occurrence **conditional logic** — not by assuming automation is exempt.

---

## Sensible Practice

1. **Grant the capability to a role, not to individuals**, so leavers lose access with their role.
2. **Keep front-end pages restricted anyway** — capability checks plus page protection.
3. **Set an Admin Email** that reaches a real person, so failures don't sit unseen.
4. **Review the Feeds tab periodically** — an active feed on a public form starts schedules for every qualifying submission.
5. **Send Copy Diagnostics rather than screenshots** of entries; the report is already redacted.