Letting students apply for themselves (Admissions), and billing them directly (Finance)

Feature Requests
1

Hi @sandra, @Ali,

I’m working with a university that needs students to apply for themselves, without a parent or family. This has come up before: arman’s recent thread Admissions and billing for adult students, and in 2020 Gibbon with no parents and fee invoices to students, where Ross mentioned he’d welcome an implementation. Before proposing any code, I wanted to share what I found and ask how you’d like it to fit with your plans for the Admissions module.

What works today with configuration alone (v30.0.01)
A copy of the Sample Application Form with the Family/Parent pages removed and Create Parents turned off submits and accepts cleanly. Create Student, Create Family (it names the family after the student), Create Invoicee and the acceptance email all work without parent fields.

Where the parent assumption remains

  • Processing fee: PayProcessingFee::verify() requires parent1email, so it can never run on a student-only form.
  • Submission email: template data only uses Parent 1’s names, so a student-only form greets the applicant “Dear ,”.
  • Form Builder requires a Parent Acceptance Template, even on forms with no parent fields.
  • Acceptance only ever links the admissions account to Parent 1, so a student’s account stays linked to nobody (or only to a family with no adults).
  • Finance: invoice recipients come only from family adults, company emails or CC Self. The student is never a candidate, so invoices to a student with no family have nobody to go to. The Company workaround works, but it duplicates the student’s own details into four required fields.

What I built and tested on v30 (offered as evidence, not as a finished design)
The rule throughout: new behaviour only applies when the form has no parent fields, so parent forms behave as before.

  • Phase 1: the processing fee and submission email use the student when there is no parent; the parent template is optional; “inform parents” only appears on forms with parent fields.
  • Phase 2: on acceptance, the admissions account is linked to the student, and the student’s email is pre-filled from the account email. The account’s person is never treated as Parent 1 when the form has no parent fields and that person is a Student. Without that guard, a returning student would be recorded as their own parent.
  • Tested end to end on the v30.0.01 release bundle, including control runs on stock v30. Parent-form regression checks pass in all runs.

Findings, patches and tests: GitHub - tiekubd/gibbon-student-self-application: Letting students apply for themselves in Gibbon: findings and tested patches for v30.0.01 · GitHub

Questions for you

  1. The roadmap mentions pre-application and post-application forms. How should “applying as a student” fit with that design?
  2. In May 2025 you mentioned making the admissions account email optional. Is that still the direction? Our changes simply do nothing when there’s no account email.
  3. A student’s second application currently creates a second student record. Would you welcome reusing the linked student on acceptance, the way returning parents are handled?
  4. Finance: would an invoiceTo = 'Student' option, reading name, address and email live from gibbonPerson, be acceptable? Or would you prefer another approach? (The invoice queries also require a form group, which is a separate question.)

What I’m offering
To rework this against the development branch to your structure (for example, a single gateway query, as you suggested on #2121), split into small PRs. Anything with new strings would naturally target v32.

Separately, a small bug I hit along the way: in SendSubmissionEmail, AddAddress($formData->has('parent1email')) passes true instead of the address, so Parent 1 doesn’t receive the confirmation copy when they aren’t the account email. It’s still in the development branch. I’m happy to send a one-line PR. (I also noticed the house assignment issue, already fixed in #2121. Thanks!)

Thanks,
Tieku

2

A quick update after thinking this through some more, which changes one part of the post above.

In many institutions, especially universities, the student applies for themselves, but the form still collects parent information: contact details from everyone, and often family income, bank statements and pay slips from scholarship or financial aid applicants. So “the form has no parent fields” is the wrong signal for “the student is applying”. On a form like that, parent fields are present and filled in, yet the student is still the one completing the application, receiving the emails and being billed.

So the rule in my post (“new behaviour only applies when the form has no parent fields”) doesn’t hold. Who is applying should be stated explicitly, not inferred from which fields are on the form.

A suggestion to react to: a form setting along the lines of “Who completes this application?”

1. A parent or guardian, for a student. This would be the default, so existing schools see no change.

2. The student, for themselves. Parent sections can still be on the form, for contacts or scholarship information.

3. Let the applicant choose. The form asks “I am a parent applying for a student / I am a student applying for myself”, for institutions that take both.

The answer would be saved with each application. Gibbon’s acceptance process and the Finance module would then use it automatically to decide who receives the emails, who the admissions account is linked to, and (later) who is billed. Staff wouldn’t need to set anything per application. Parents and families would still be created from the parent fields whenever the school wants them.

What we built on v30 stays the same in substance. The check would just change from “no parent fields” to “the applicant is the student”, in one shared place instead of several. I’ll hold off on that rework until I hear whether this direction fits your plans for the Admissions module, especially the pre- and post-application forms.

Thanks,

Tieku

3

One more refinement, as we keep working through this.

In my last post I suggested three choices for “Who completes this application?”, the third being “Let the applicant choose”, where the form itself asks whether a parent or the student is filling it in. On reflection I’d drop that option.

Gibbon already handles this well: the application page lists every active form by name and description. An institution that takes both kinds of applicant can publish two forms, for example “Application by a parent or guardian” and “Application by a student (applying for yourself)”, and the applicant chooses by choosing the form. That follows the existing advice to create separate application forms for different situations. It also keeps each form predictable, because the emails, the account linking and (later) billing then follow the form chosen. And it avoids adding another question and field to the form.

So the suggestion is now a single setting per form:

  1. A parent or guardian, for a student (the default, so existing schools see no change)
  2. The student, for themselves (parent sections can still be on the form, for contacts or scholarship information)

The trade-off is that a school taking both kinds of applicant keeps two similar forms in step. That seems a fair price for a simpler and more predictable setup, but I’d welcome other views.

I’m testing this on a fresh v30.0.01 site with demo data in the meantime, and as before I’ll wait to hear whether it fits your plans for the Admissions module before going further.

Thanks,

Tieku