From 990dc94957a1187712ae7f6e7196a8924e1bf97c Mon Sep 17 00:00:00 2001 From: Habibur Rahman Delwar Date: Fri, 28 Aug 2026 13:37:56 +0600 Subject: [PATCH] Docs: note that the status filters are now enforced Both status vocabularies are validated at the write path from the next release (current stable is 6.2.13), so a status that is not registered through its filter can no longer be applied. Previously either endpoint would write whatever string it was handed. fluentform/entry_statuses_core - entry status writes are checked against the per-form list. Add-ons that gate their statuses on a feature being active only contribute while it is enabled, so a row can hold a status that cannot be re-applied once the feature is off; the base statuses stay available. fluentform/available_payment_statuses - the same for the admin transaction endpoint, with one difference worth stating: validation runs only when the status actually changes, so a row already holding an unregistered status keeps it and its other fields stay editable. Also corrects the location note. Two classes define the payment list and both apply the filter - the free PaymentHelper as well as Pro's - and the example array shown is Pro's. 'requires_review' is Pro-only and absent from the free list, which is exactly why a status should be registered through the filter rather than assumed from a hardcoded default. Refs: https://lounge.authlab.io/projects#/boards/16/tasks/22737-Security%3A-form-scope-bypass-an --- src/hooks/filters/payment.md | 11 ++++++++++- src/hooks/filters/submission.md | 10 ++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/src/hooks/filters/payment.md b/src/hooks/filters/payment.md index 6c74f0d..c14ec61 100644 --- a/src/hooks/filters/payment.md +++ b/src/hooks/filters/payment.md @@ -117,7 +117,16 @@ $paymentStatuses = [ `apply_filters('fluentform/available_payment_statuses', $paymentStatuses);` -This filter is located in FluentFormPro\src\Payments\PaymentHelper -> getPaymentStatuses() +::: warning Registering a custom status is required +Changing a transaction's status from the admin is validated against this list, so a status +that is not registered here cannot be selected or applied. + +Validation only runs when the status actually changes. A row that already holds a status +this build does not register keeps it, and its other fields (payer name, email, addresses) +remain editable. +::: + +Two classes define this list and both apply the filter: `FluentForm\App\Modules\Payments\PaymentHelper` (free) and `FluentFormPro\Payments\PaymentHelper` (Pro). The array above is Pro's — `requires_review` is Pro-only and is not present in the free list, so register any status you rely on through the filter rather than assuming a hardcoded default. diff --git a/src/hooks/filters/submission.md b/src/hooks/filters/submission.md index a3b4435..24b06d1 100644 --- a/src/hooks/filters/submission.md +++ b/src/hooks/filters/submission.md @@ -345,6 +345,16 @@ add_filter('fluentform/entry_statuses_core', function ($statuses , $form_id) { This filter is located in FluentForm\App\Helpers\Helper -> getEntryStatuses($form_id = false) +::: warning Registering a custom status is required +Entry status writes are validated against this list. A status that is not registered here +cannot be set — neither the bulk action nor the single-entry endpoint will apply it. + +The list is resolved per form, and add-ons that gate their statuses on a feature being +active (Admin Approval, double opt-in) only contribute while that feature is enabled for +the form. Existing rows keep a status after the feature is turned off, but it can no longer +be re-applied; the base statuses stay available for triage. +::: +