> Also on deletions - it would be great to have a 'deleted timestamp' > (forgive me if this is in the upcoming 2.0 release, I haven't > checked the code). That way you can purge messages from the database > once they've been *marked as deleted* for more than <user > configurable> days. A grace-period if you will where helpdesks can > 'save the day' for unsavvy users.
Um, this is already possible. On our sites, we run the dbmail-maint program each morning, deleting messages that the system has tagged as deleted (status 003), then marking user-deleted messages (status 002) as system deleted. This gives at least 24 hours for a customer to decide that they need to have a message undeleted. On a client's site, that task is only run on the first of the month, giving 28+ days. Putting it on a weekly cron job would do the same, with a 7 day minimum grace period. Implementing a by-timestamp would be simple enough, though. Just add a timestamp field to the table. The last user-induced change would be the deleting the message. You could then run a query to make changes based upon status=002 and timestamp older than X days to change the status to 003, then let the normal maintenance program take over at that point for the final deletion. -- Jeff Brenton President, Engineered Software Products, Inc http://espi.com Questionable web page: http://dididahdahdidit.com Liberalism grants you the freedom to advocate any idea*. * Please see http://www.dididahdahdidit.com/except.php for a current list of exceptions
