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

4

Quick update: I’ve now tested the two-option version on a fresh v30.0.01 site with demo data, and updated the repository with the package, findings and tests. Testing turned up a few bugs that affect any school, not only student applications. I’ve reported them separately so they can be looked at on their own: two GitHub issues (#2183 and #2184), and one by email to support, as it involves login details. The suggestion in this thread is unchanged.

Thanks,
Tieku

application_form_choice
application_form_choice707×908 57.3 KB

formbuilder_setting_2options
formbuilder_setting_2options1200×1000 92.5 KB

5

Hi Tieku,

I noticed you have referenced my post Admissions and billing for adult students.

This is how I handle it without code changes in 30.0.1.

I have created two triggers in the database:

  1. before_invoicee_insert trigger - triggers whenever a new Invoicee is created.

It pretty much sets it as company with the same name and email as the student.

CREATE TRIGGER `before_invoicee_insert` BEFORE INSERT ON `gibbonFinanceInvoicee` FOR EACH ROW BEGIN
    -- Declare local variables to hold the data
    DECLARE v_firstName VARCHAR(60);
    DECLARE v_surname VARCHAR(60);
    DECLARE v_email VARCHAR(75);

    -- Fetch multiple fields into variables in one query
    SELECT firstName, surname, email
    INTO v_firstName, v_surname, v_email
    FROM gibbonPerson 
    WHERE gibbonPersonID = NEW.gibbonPersonID
    LIMIT 1;

    -- Assign those values to the row being inserted
    SET NEW.companyName = CONCAT(v_firstName, ' ', v_surname);
    SET NEW.companyContact = CONCAT(v_firstName, ' ', v_surname);
    SET NEW.companyEmail = v_email; -- Ensures invoice goes to student/company email
    SET NEW.invoiceTo = 'Company';
    SET NEW.companyCCFamily = 'N';
    SET NEW.companyAll = 'Y';
END
  1. after_person_update trigger - Every time when a person is updated, it also updated the Invoicee:
CREATE TRIGGER `after_person_update` AFTER UPDATE ON `gibbonPerson` FOR EACH ROW BEGIN
	UPDATE gibbonFinanceInvoicee 
	SET companyName = CONCAT(NEW.firstName, ' ', NEW.surname),
		companyContact = CONCAT(NEW.firstName, ' ', NEW.surname), 
		companyEmail = NEW.email -- Ensures invoice goes to student/company email
	WHERE gibbonPersonID = NEW.gibbonPersonID;
END

With this approach the student receives the billing related communication and pays invoices as well.

I don’t have to create a family since the payments are handled by a “company”.

Regards!

6

Hi Arman,

Thanks for posting the triggers, and for the original thread. It was a big part of what got me looking at this. For a school where every student is an adult, it’s a neat way to get billing working on v30 today without touching code. The update trigger also solves the drift problem I saw when company details were entered by hand.

A few things I noticed reading through them, for anyone else trying this:

  1. The insert trigger applies to every invoicee, so at a school that also has parent-led applications every child would be billed as a company, with the family not copied in. That includes invoicees created automatically on the Manage Invoicees page.
  2. It replaces whatever payment option the applicant chose on the form, so a student genuinely sponsored by a company would lose those details. The update trigger would also overwrite real company details whenever that person’s record changes.
  3. If the application form uses Gibbon’s default New Student Details setting, the student’s email becomes username@localhost.test. It’s worth changing that setting, as you may already have done, so the applicant’s real email stays as their primary email.
  4. Address and phone aren’t copied, so they only appear on invoices if they were entered separately.

This is close to what I’d like to see in core: an invoice option of “Student” (or “Myself”) that reads the name, address and email live from the student’s record, set per application form. Nothing would be copied, and schools could still take parent-led applications alongside. I’ll bring that to the Finance discussion once the Admissions side has had some feedback.

Thanks.

7

Based on our experience with the application form section in Gibbon, we are currently facing a significant issue that we believe is relevant to this discussion.

Regarding the possibility—raised in this thread—of allowing students to apply for admission and enrollment directly, without the prior involvement of a parent or guardian, we have observed that our current challenges go beyond the simple lack of a dedicated application workflow for students.

Even when using application forms that include fields , the system does not automatically generate user credentials for the student or for the parent or guardian whose details are submitted.
This creates a substantial obstacle in our admissions process, as individuals who complete the form—and are subsequently accepted—do not have their system credentials automatically created based on the information they provided during registration. Consequently, additional manual steps are required to create and manage their accounts.

We believe it would be very beneficial to review how the admissions form module, account creation, and credential generation are handled—both for applications submitted by parents or guardians and for those submitted directly by students.

8

Hi @beafranco_co1,

On logins for accepted applicants: in my testing on v30.0.01, Gibbon does create them. It does so at acceptance, not at submission, and only when a few settings are in place. These are the ones I’d check, all in System Admin > Form Builder > (your form) > Active Features:

  1. Create Student and Create Parents set to Yes. On acceptance, these create the Gibbon user accounts and generate a username and password for each new person.
  2. A Student Acceptance Template and a Parent Acceptance Template chosen, under Notification Options. These are the welcome emails that send the login details.
  3. The “inform student” and “inform parents” boxes on the Accept page. If they aren’t ticked when an application is accepted, the accounts are still created, but no one is told their login details. Student Notification Default and Parents Notification Default control whether they start ticked.
  4. Student Email & Website, under Acceptance Options. If it’s Yes and a Student Default Email pattern is set (for example username@localhost.test), the student’s email is replaced with that pattern on acceptance, so their welcome email may go to an address nobody reads. Set it to No, or leave the pattern empty, if students should keep the email they applied with.

Before acceptance, applicants only have an admissions account: their email address plus the link they’re emailed to return to their application. That isn’t a Gibbon login, so nobody has system credentials until the application is accepted.

Before using the welcome emails with real applicants, I’d recommend testing acceptance with a few of your own email addresses, as student and parents, and checking that each person receives only their own email.

I hope this helps.

Thanks,
Tieku

9

Hi @sandra,

Before the update, I want to say how much I’ve come to appreciate the Admissions module you designed. Working through it in this much detail has shown how carefully it was thought out. The form builder lets each school shape its own forms. Each feature, from emails and fees to creating the student, family and invoicee, is a separate process that can be switched on per form, can check itself and can be rolled back. And the admissions account lets families return to their applications without a login. It’s why so much of this work could be built inside the existing design rather than around it. In my work with schools, admissions is often the reason they choose Gibbon in the first place. Thank you.

Update: a proposal for billing the student directly, and two more bug reports

Following on from the Finance question in my first post, I’ve built a working prototype of billing the student directly, to help the discussion. It is offered as a proposal and evidence, not a finished design, and only exists in my repository as a package for v30.0.01. I tested it on a fresh v30.0.01 site with demo data and the PayPal sandbox.

What it proposes: a third choice for who invoices go to, Student, beside Family and Company.

  • On forms set to “The student, for themselves”, Send Future Invoices To would offer Myself, Family or Company, with Myself selected. Parent forms would be unchanged.
  • On acceptance, the student’s invoicee would be set to Student. Staff could also choose Student in Manage Invoicees and in the Data Updater.
  • Invoices, reminders and receipts would go to the student, using their name, email and address read from their own record at the time, so nothing is copied into company fields.
  • Students could see their own invoices with the existing View Invoices_mine permission.

It needs the value Student added to invoiceTo in three tables. Nothing in the development branch changes those columns, so it wouldn’t clash with v31.

Testing the online payments turned up two bugs in current Gibbon that affect every school taking invoice payments online. I’ve reported both:

I’d welcome your view on both parts of the proposal: the per-form setting for who completes the application, and Student billing. In particular, does this direction fit your plans for the Admissions and Finance modules? I’m happy to rework either to your structure and split them into small pull requests, for whichever release you think fits. Since they add new strings, I understand v31 is too late.

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

Thanks,
Tieku