Sponsor renewal does not port all information to the new sponsorship row

[hyanwong]

@jrosindell and I have just tried renewing a species on the production server, and there appears to be a serious bug. The original row is transferred OK to the expired_reservations table, but the details remaining in the original reservations table are bad. Here are the first few fields, which are OK.

And the user_sponsor_name has transferred OK. But all the other fields, such as username, e_mail, user_sponsor_kind, user_giftaid, and all the verified_XXX fields are empty. This might be because a new row has been created for the entry (and the old one deleted), as evidenced by the fact that the ID in the snapshot above is a high number (almost the last row added to the reservations table, at the moment). I suspect (but am not sure) that we intended to copy the row to expired_reservations and then update it, rather than delete the existing row it and create new one. Is that right @lentinj.

[jrosindell]

@lentinj - while you're on this I wonder if you could also please add to the sponsor_renew_reminder e-mail text an additional reference to that user's personal sponsorship page - currently that's referenced from the renewal html page only. I think it's nice for the user to see this from the e-mail as well.

[jrosindell]

I'm about to push some updates to improve the e-mail template but please do check the controller serves the correct things to make it work - thanks @lentinj

[lentinj]

@hyanwong This sounds familiar, I suspect a patch has fallen down the back of a sofa. Will have a look tomorrow and let you know.

[lentinj]

This might be because a new row has been created for the entry (and the old one deleted), as evidenced by the fact that the ID in the snapshot above is a high number (almost the last row added to the reservations table, at the moment). I suspect (but am not sure) that we intended to copy the row to expired_reservations and then update it, rather than delete the existing row it and create new one. Is that right @lentinj.

No, this is expected. Renewing by expiring and repurchasing in a single transaction means we can share code with the expire then repurchase case.

I can't reproduce with the tests yet, will try doing something end-to-end. Just to check, this is 3.7 with https://github.com/OneZoom/OZtree/commit/0e0165c367a82de14da83502e98d86e16238ee4f ?

[jrosindell]

@lentinj not it's not with 3.7 I think the server is still running 3.6

[jrosindell]

I think this is now fixed based on the changes Yan and I made to the renewals system recently so I'm closing. Having tested it just now with another renewal all seems to be fine.