6.0.0-beta1
7/10/25

[#1664] Delete Vacation DB on Disable
Summary Delete Vacation DB on Disable
Queue Ingo
Queue Version 1.0.1
Type Enhancement
State Rejected
Priority 2. Medium
Owners ben (at)
Requester lecaptainc (at) itol (dot) com
Created 04/01/2005 (7405 days ago)
Due
Updated 12/28/2007 (6404 days ago)
Assigned 10/23/2005 (7200 days ago)
Resolved 12/28/2007 (6404 days ago)
Milestone
Patch No

History
12/28/2007 11:10:53 PM Chuck Hagenbuch Comment #7
State ⇒ Rejected
Reply to this comment
Ben's explanation makes sense to me and this has been sitting for two 
years. Rejecting.
10/23/2005 01:03:54 PM Jan Schneider State ⇒ Assigned
 
05/23/2005 03:34:01 AM ben Comment #6 Reply to this comment
Ah, I see what you are saying now.  The following lines of the 
generated script handle deleting an old database:



   5:   FILEDATE=`ls -lcn --time-style=+%s 
'vacation.test@ben.chavet.net' | awk '{ print $6 + (604800) }'`

   6:   DATE=`date +%s`

   7:   DUMMY=`test $FILEDATE -le $DATE && rm 'vacation.test@ben.chavet.net'`



The database is deleted if it was created more than X days ago, where 
X is the user-defined "Number of days between vacation replies" on the 
vacation form.  So, re-enabling the vacation script will result in a 
new database if it has been more than X days since it was created.



So, this functionality isn't exactly obvous from the user's 
perspective. But if we hide the database files, it should just be a 
transparent thing that "just works" for the user.



The only potential problem I can see with this is if the user chooses 
some insanely large number of days to keep the database.
05/09/2005 05:06:34 AM lecaptainc (at) itol (dot) com Comment #5 Reply to this comment
That's fine, but that doesn't really resolve the problem, the vacation 
DB would still exist afterward and wouldn't be emptied for the next 
time the vacation message is created, giving us the same problem, or 
am I getting this completely wrong?
05/09/2005 04:19:52 AM ben Comment #4
State ⇒ Feedback
Reply to this comment
I don't know if I'm comfortable with deleting files that ingo doesn't 
directly generate.  What if we were to modify the script to put the 
vacation cache in a hidden directory or hidden file?  Something like:



     .vacation/username1@example.com



or



     .vacation.username2@example.com



I'm personally in favor of the first one.
04/07/2005 04:32:51 PM Jan Schneider Assigned to ben
State ⇒ Assigned
 
04/07/2005 04:27:11 PM lecaptainc (at) itol (dot) com Comment #3 Reply to this comment
Currently I'm using the 'prefs' driver, which is then using a vfs driver:



It does work, it writes the .procmailrc script just fine, and the 
vacation database shows up, it's just not deleted when I choose to 
disable the vacation message in Ingo.



backends.php:



$backends['procmail'] = array(

     'driver' => 'vfs',

     'preferred' => 'domain.com',

     'hordeauth' => true,

     'params' => array(

         'hostspec' => 'ftp.domain.com',

         'procmailrc' => '.procmailrc',

         'port' => 21,

         'vfstype' => 'ftp'

     ),

     'script' => 'procmail',

     'scriptparams' => array(

         // What path style does the IMAP server use ['mbox'|'maildir']?

         'path_style' => 'mbox',

         'variables' => array(

             // Example for the $PATH variable

             // 'PATH' => '/usr/bin'

         )

     )

);
04/07/2005 04:20:02 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Which driver are you using? I don't think any driver we currently have 
supports that.
04/01/2005 08:13:32 PM lecaptainc (at) itol (dot) com Comment #1
Priority ⇒ 2. Medium
Type ⇒ Enhancement
Summary ⇒ Delete Vacation DB on Disable
Queue ⇒ Ingo
State ⇒ New
Reply to this comment
Currently, when I enable a vacation message, it creates a database of 
users that have gotten the vacation message from me, so as not to spam 
the person.  When you disable the message, the database of users isn't 
deleted, it remains.  On disable, give an option to delete the database?

Saved Queries