Permissions
Forms Pro adds permissions to Grav's account system, so you decide who can build forms and who can only handle what visitors sent. They apply to Admin Next and the REST API. Anyone on the public site can fill in and send a form, whatever their account.
The permissions
An account needs api.access (the general permission to use Admin Next and the API) plus one or more of these. Super users have all of them.
| Permission | Label in the account editor | Allows |
|---|---|---|
api.forms-pro.forms.read |
Forms Pro, Read Forms | See the forms list, open a form in the builder (read-only), see its YAML export, and load the field and action catalog. |
api.forms-pro.forms.write |
Forms Pro, Manage Forms | Create, change, duplicate and delete forms. Give it together with read. |
api.forms-pro.submissions.read |
Forms Pro, Read Submissions | See the Entries section and a form's Entries tab, open entries, download their files and export them. |
api.forms-pro.submissions.write |
Forms Pro, Manage Submissions | Mark entries read or unread, star them, write notes, and delete them. |
api.forms-pro |
Forms Pro API (Full) | A parent key: grants all four above. |
Grav treats a permission as covering everything under it, so api.forms-pro.forms grants both forms.read and forms.write, and api.forms-pro grants all four. write does not include read: give an account both when it should be able to change what it sees.
Some actions need two permissions:
- Deleting a form needs
forms.writeandsubmissions.write, because deleting a form deletes its entries too. The delete confirmation says how many entries go with it. An account that can edit forms but not manage entries sees a note that it needs the Manage Submissions permission as well. - Opening an entry marks it read only for an account with
submissions.write. An account with onlysubmissions.readcan open entries and they stay New.
What each account sees
Admin Next hides what an account cannot use, so people are not offered buttons that would only fail.
- Forms Pro appears in the sidebar for an account with
forms.read,submissions.readorapi.forms-pro. - An account with
forms.readandforms.writesees the builder with a Save button. - An account with
forms.readonly sees each form read-only, with a notice (Your account can view this form but not change it). The forms list shows a similar notice. - An account with
submissions.readand notforms.readis an entries-only account. The Forms Pro page opens on Entries, with the list of forms that have entries, and there is no builder. The unread badge on the sidebar item still works for it. - An account with none of the four permissions sees Nothing to show, with a message to ask an administrator for the Forms Pro permissions.
Sample groups
Create groups under Accounts and give people the group:
| Group | Permissions |
|---|---|
forms-editors |
api.access, api.forms-pro.forms.read, api.forms-pro.forms.write |
forms-readers |
api.access, api.forms-pro.submissions.read |
forms-inbox |
api.access, api.forms-pro.submissions.read, api.forms-pro.submissions.write |
forms-admins |
api.access, api.forms-pro |
In an account's YAML, the same thing for a group looks like this:
access:
api:
access: true
forms-pro:
submissions:
read: true
write: true
Permissions on forms and the site
- The permissions govern what an account can do in Admin Next and through the REST API. They do not hide a form from site visitors. A form is public wherever you embed it.
- Entries hold what visitors typed, often personal data. Give
submissions.readto as few people as needed, and remember that anyone with it can export every entry of every form. - There are no permissions for a single form. The four apply to all forms.
- The Call Function action runs PHP, so it is hidden unless Expose Call Action is on in the plugin settings, whatever the permissions. See Configuration.