Bug in receipt emailing

General
1

Hi folks,

When I register a payment and send an email of the receipt to myself or a parent, the payment details don’t show. It says “There are no records to display.”

Can you reproduce this?

Kind regards,
Roman

2

Let me add the following:

The first payment seems to work just fine. The problem starts with the second.

3

Hi Roman,

Can you share some steps to reproduce this issue? It’ll help diagnose the issue quicker.

Thanks!

4

I’m using v17:

  1. add a new invoice
  2. issue it
  3. register first partial payment → works nicely
  4. register second partial payment → issue occurs

I suspect an issue with how the receipt number is retrieved in file invoices_manage_editProcess.php line 224.

Not sure tho.

5

Nothing? Anybody? :slight_smile:

6

@ross: help me out? Please? :slight_smile:

7

Hi Roman, Sandra’s got her hands full, but I am hear to help : ) Sorry for the delay. I’ve tried to recreate this in v19, and it seems to be working fine:

Are you getting a PHP error, warning or notice? Can you try a v19 install and see if you can recreate the issue there? It may be something that got fixed, but that I can’t recall.

Thanks!

Ross

8

Hi Ross,

Thanks for taking over this issue :slight_smile:

I obviously didn’t explain myself correctly.

Within the Gibbon web interface things are just fine for me as well. I was rather referring to the content of the email sent to the parent or cc.

It doesn’t show the payment details. Instead it says “There are no records to display.”

Again this issue starts occurring with the second payment.

I have attached a pic for you to see, how it looks like.

Hope this will make things clearer. Sorry again :slight_smile:

Kind regards,
Roman

9

Hi Roman, sorry for the delay in replying. Busy times at the moment. Thanks for taking the time to explain the issue. I don’t have outgoing emails configured in my dev environment at the moment, but I think we can sort this out between us.

I believe this error is being generated on line 1538 of /modules/Finanace/moduleFunctions.php. It is based on the $paymentFail flag being set to true. This can occur on lines 1338, 1346 or 1351. However, I cannot recreate it in the Print view, and so I guess it is specific to emailing.

Are you able to add:

echo ‘1338’; exit;

To the end of the line 1338, and similar to 1346 and 1351, in order to see exactly what is causing the issue?

Once you let me know the line number I can look into it in more details.

Cheers,

Ross

10

Hi Ross,

Nice! You were right!

$paymentFail flag is set at line 1351 :slight_smile:

Hope this helps!

Kind regards,
Roman

11

Getting closer! Can you please echo line 1342 ($sqlPayment), and then add:

echo $resultPayment->rowCount();

to the start of line 1351?

Share the two outputs with me, and then we’ll know more.

Closer and closer we get ; )

12

Ok, here we are:

$sqlPayment:
SELECT gibbonPayment.*, surname, preferredName FROM gibbonPayment JOIN gibbonPerson ON (gibbonPayment.gibbonPersonID=gibbonPerson.gibbonPersonID) WHERE foreignTable=:foreignTable AND foreignTableID=:foreignTableID LIMIT 2, 1

$resultPayment->rowCount():
0

I’m sure you expected this, didn’t you? :slight_smile:

13

I was thinking that we might see this, yes : )

I need you to test this on your database directly, but the two PDO parameters need to be converted into values, like:

SELECT gibbonPayment.*, surname, preferredName FROM gibbonPayment JOIN gibbonPerson ON (gibbonPayment.gibbonPersonID=gibbonPerson.gibbonPersonID) WHERE foreignTable=‘gibbonFinanceInvoice’ AND foreignTableID=‘00000000000001’ LIMIT 2, 1

Just replace 00000000000001 with your own gibbonFinanceInvoice ID. Can you work out why it is not returning anything? Try removing LIMIT 2, 1 to see how many records you get.

LIMIT 2 means this is the third partial payment (counting from 0).

Keep digging, you’ll get there!

Ross

14

Hi Ross,

receiptContents is called twice if an email is sent. I think the problem comes from receiptContents being called with different values in $receiptNumber. The first time it’s right and the second time it fails.

The way $receiptNumber is determined in invoices_manage_editProcess.php line 224 may not work as I mentioned to Sandra earlier on.

I think there’s somehow a mixup of $receiptNumber and $receiptCount. Anyway, I’m still stuck and may be wrong.

Kind regards,
Roman

15

Hi Ross,

It seems I really got it wrong in my previous assessments. Gosh :slight_smile:

It looks like it’s rather a commit issue that is causing this issue.

The following two things happen in file invoices_manage_editProcess.php:

  1. The payment is recorded
  2. The email is prepared and sent

At the time the email is prepared going through receiptContents the payment has not been commited to the database yet.

Therefore we get the paymentFail from above.

How can we commit the new record to db before preparing the email?

What do you think? Did I miss it again?

Kind regards,
Roman

16

Hi Ross,

I think I finally got it right. No guarantee tho :slight_smile:

It seems not to be a commit issue but the fact that the payment is recorded very late in invoices_manage_editProcess.php function setPaymentLog.

When preparing the email that data is simply not available yet.

Did I get it right this time?

Kind regards,
Roman

17

Nice detective work! :smiley: Yes, it looks like it was a combination of the setPaymentLog needing to be before the email sending, and an off-by-one error of the $receiptNumber being used as an index (starting at 0), but provided as a count (starting at 1).

As luck would have it, Jian must have also encountered the bug and had submitted a PR with the fix. I’ve merged it into v19, be sure to test it out and give a shout if it’s still not working (you can also apply these changes line-by-line back to v18 as needed).

Thanks!

18

I have tested it and it works like a charm :slight_smile:

Thanks guys!