Skip to content

Added handling for integer (i.e. timestamp) values when setting created/modified field values.

Robert Sinton requested to merge patch/populating_timestamp_fields into feature/encryption

Background

In AFES, application/modules/donations/controllers/donations.php, line 71, we instantiate and populate a donation result object using data that comes from decrypting a database record by using a token.

$details = $this->token_access_model->get_token($encrypted_donation_token);
...
$donation = new afes_donations_result((array) $details->data->donation);

The decrypted data includes a created property whose value is an integer, i.e. the raw timestamp value from the original record. I found that DF_Model_result's magic __set method was always assuming that the incoming value for a created or modified property was a string date/time representation, and was performing a strtotime() on it, which effectively cleared the property in this case.

This update checks the type of the incoming value, and if it is an integer it assumes that it is a genuine timestamp value already, and doesn't convert it.

What I did

  • Added special handling of integer (i.e. timestamp) values when setting created/modified field values.

Implications

  • I have submitted this as a patch merge to master; I'll need to then cherry-pick it into the feature/encryption branch for AFES's use.
  • It occurred to me while writing this description: how are we ending up with the raw integer timestamp value here, when presumably we normally don't? Is there a mechanism — somehow not firing in this case — that normally converts the database timestamp to a date/time string when a record is loaded? Perhaps we should instead change the decryption logic here to make sure that happens? OTOH this approach does seem like a reasonable safeguard.

Setup

None

How to test

  • Code review
  • Test with code that instantiates a result object with data that includes integer (i.e. timestamp) created/modified values. Confirm that those values are lost before this change, but preserved with the change.
    • I tested by creating a donation in AFES and using the [Print receipt] button in the "thank you" email. Note that you need to remove the resulting PDF receipt file each time around, as it will only create it if it's not there.
    • The observable change in this case is that the "Date submitted" in the top right corner is the intended date, not "Jan 1 1970".
Edited by Robert Sinton

Merge request reports