dev/core#6606 Default status Pending for new backoffice contributions#36065
Merged
mattwire merged 2 commits intoJul 13, 2026
Merged
Conversation
|
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
PR commands & links...
|
magnolia61
changed the title
magnolia61
force-pushed
the
fix/eventfees-pending-contribution-default
branch
from
June 24, 2026 07:12
998c81c to
53f6d54
Compare
…e event contribution When editing a participant registration in the back office and checking "Record Contribution", the Payment Status field had no explicit default, causing the browser to select the first option — Completed (id=1) — because getPendingAndCompleteStatuses() orders Completed before Pending by numeric ID. A newly recorded back-office contribution has not been received yet, so Pending is the semantically correct default.
magnolia61
force-pushed
the
fix/eventfees-pending-contribution-default
branch
from
June 24, 2026 07:14
53f6d54 to
29d9efe
Compare
magnolia61
changed the title
magnolia61
changed the title
Contributor
|
This is not the only place it defaults to completed on backoffice forms. I agree that it is better to default to pending. |
mattwire
added
the
merge ready
mattwire
changed the title
mattwire
removed
the
merge ready
…ibutions When creating a new contribution via the back-office contribution form, the Payment Status field had no explicit default, causing the browser to select the first rendered option (Completed) because buildOptions() returns statuses in numeric order and Completed has id=1. A newly recorded back-office contribution has not been received yet, so Pending is the semantically correct default.
magnolia61
changed the title
Member
|
I agree this makes sense. A common use-case would be for invoicing people. The payment must be pending, then send a payment link (or PDF). You have to remember to set to pending, otherwise you cannot edit and set it back to pending. If they are entering contributions received by direct transfers, then worst case they later record a payment. |
Member
|
@mattwire I noticed you removed merge-ready, is it because you would like the other places to be changed as well? Do you know where they are? For example:
Fun fact: New Membership does not "record payment" by default, but New Event does. Separate topic, but I would be tempted to not "record payment" by default. |
Contributor
|
@mlutfy well @magnolia61 pushed another commit since. Yes I would like to see the other places updated but let's do that in a follow -up PR |
Contributor
|
I've made some comments on the lab ticket. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
When creating a new contribution via the back-office — either by editing a participant registration and checking "Record Contribution", or by creating a contribution directly — the Payment Status field defaulted to Completed instead of Pending. Pending is the correct initial status according to the new philosophy on contributions and payments. See also: lab.civicrm.org issue #6606
Before
The Payment Status dropdown defaults to Completed when opening the participant edit form with "Record Contribution" checked (and no existing online pending contribution), or when opening the new contribution form. The administrator must manually switch to Pending before saving.
Payment Status: [Completed] ← incorrect default
After
The Payment Status dropdown defaults to Pending in both forms.
Payment Status: [Pending] ← correct default
Technical Details
The fix adds an else block in two places that explicitly sets contribution_status_id to Pending when no existing contribution status is present:
Without this, the browser selects the first rendered option. Because
getPendingAndCompleteStatuses()happens to return Completed (id=1) before Pending (id=2), Completed was silently selected as default.Comments
This is more in line with the philosophy of a contribution that is always pending and payments that are made towards it.