Removal Date

This has been addressed, but not exactly as described here. I'd long been intending to automatically move items from the user's public wishlist to their private wishlist a certain number of days after the item had been purchased.

There is now a configuration item for how long a fully purchased item will remain on the wishlist after the final bit of it (for multi-bit items) has been bought. A cron job will move these items into the user's private wishlist area.

I may have done the date calculation wrong for when to move items. I'll admit that this final feature I put in during the hours before we went into labor *may* not have received enough testing... Knowing you were willing to help and would scour the module allowed me to choose to commit earlier than I otherwise might have. I do appreciate your help. I'll put in some further diagnostics. One that I recommend you do is to modify wishlist_cron() to add the following watchdog to help diagnose:

	// Calculate the time before which we will go looking for items that are fully purchased.
	$time = time() - (variable_get('wishlist_item_expire_days', 30)*24*60*60);

	watchdog('wishlist', "Removing items purchased before ".format_date($time));

In going in to type this watchdog in on my own to cycle back for testing later I think I see the problem. I'm comparing against the wrong date in the SQL. With no certification at all (I'm in the hospital after hours of sleep to catch up for the hours of no sleep during my wife's labor, and she and the baby are out cold), not even a syntax check, here is a replacement SQL statement for wishlist_cron(). The change is to compare against 'compare_date' in the having clause rather than the p.purch_date in the where clause.

	$sql = "SELECT p.*, MAX(p.purch_date) as compare_date, SUM(p.wishlist_purch_quantity) as purchased, n.title, n.nid, w.item_is_public, w.item_quantity_requested FROM {wishlist_purchased} p 
 			INNER JOIN {node} n ON n.nid = p.wishlist_purch_nid
			INNER JOIN {wishlist} w ON n.nid = w.nid
 			WHERE w.item_is_public = 1
			GROUP BY n.nid 
			HAVING purchased >= w.item_quantity_requested
            AND compare_date < %d
			ORDER BY compare_date LIMIT 100";

Give those changes a try and see if it works better. I'll be back in a place where I have commit access in a few days. The hospital gives me port 80 access only.

It just struck me that I should have asked this: are the wishlist items that are being moved ones that were purchased prior to this latest version of the module being installed? If so, then I do expect them to move. All of them have a purchase date of 0, since that field was recently added, and thus all are caught by the cron job.

I had a choice to make to either leave pre-upgrade purchases on the list, or to hide them. I choose to hide them.

I just thought of another choice: when the upgrade script is run I can set the purchase date for all existing entries to 'right now' so that they will expire off 30[default] days after the upgrade. What do you think of that route?

Regardless, the SQL change I posted a little earlier tonight will still make it in as I should be testing the date in the having clause.

Done, an upgrade will now include setting the purchase date of all existing purchase records to 'now'.