You have the possibility to filter the capabilites using the notification/post_type/capabilities hook.
When you change this to a value notmanage_options, the API to endpoints of /repeater-field/(?P<id>\d+), /section-repeater-field/(?P<id>\d+) or repeater-field/select are only accessible by the capability manage_options. See example.
The problem with this, when a user without the cap manage_options, and he/she edits a notification with one or more recipient repeat-fields, this user does not see the repeat-fields (a 403 response is given when fetching the fields). And when this user saves the notification, the recipients fields are not saved to the notification, which results in no recipients getting mailed.
Expected behavior
The repeated fields should be accessible to anyone who has the ability to edit notifications.
Thanks for the report @edwinsiebel ! This should be an easy fix. I'll make sure to attach the changelog here if you'd like to hotfix before the next release.
Bug description
You have the possibility to filter the capabilites using the
notification/post_type/capabilities
hook.When you change this to a value not
manage_options
, the API to endpoints of/repeater-field/(?P<id>\d+)
,/section-repeater-field/(?P<id>\d+)
orrepeater-field/select
are only accessible by the capabilitymanage_options
. See example.The problem with this, when a user without the cap
manage_options
, and he/she edits a notification with one or more recipient repeat-fields, this user does not see the repeat-fields (a 403 response is given when fetching the fields). And when this user saves the notification, the recipients fields are not saved to the notification, which results in no recipients getting mailed.Expected behavior
The repeated fields should be accessible to anyone who has the ability to edit notifications.
Environment
Screenshots
Admin user:
Editor user: