rewrite method that PIFT uses to collect files for testing

@catch: we have to move the code, test it, and deploy it on d.o in a sensible way.

i don't really have time to work in this right now. would be great if somebody could take up the ball for a little bit.

geez, did anybody even read how the add file function works?? ;)

the cron based approach tracked file ids to know what it last checked, but we don't want to do that now. at the time an issue or followup is submitted by the user, we want to examine every file that's attached, compare it against the regex for what pift considers a patch file, and then add the file to {pift_data} if necessary. note that because project, rid, and sid can all change, we cannot use these to filter what files go into {pift_data} for tracking. _all_ files attached to issues or followups that fit the file regex must be put into {pift_data}

the add files function should either completely die, or be converted into a script that an admin would run once to get any old files added to the {pift_data} table before they turned their site back on out of maintenance mode.

sorry guys, i don't think this is going to be just a few lines of change...

@pwolanin: i'm not sure why you set this back to CNR -- i won't accept the patch as written, it needs to be adjusted as i outlined in #7!

guys, i'm not seeing any patches attached to these followups -- are we having a technical problem w/ attachments?

an update doesn't make any sense here. pift_server_reset_send_queue() is called during initial install with the express purpose of making it so that the server begins to operate on files that are attached after it's initially installed.

i believe this is the most sane way to install the module. the only other sane way to do it would be to use batching to examine and insert all appropriate files related to issues upon initial install -- which is a really bad idea for d.o.

so if operating only on files since the module was installed is our installation strategy, then we don't want an update that grabs any old files, and since we're inserting new files dynamically, then the entire fid tracking system should be removed. this includes a rewrite of pift_server_reset_send_queue(), removing pift_server_get_newest() and pift_server_get_last(), and using update 1 to remove the associated dead variables.

the script which would grab old files would ideally have some settings you could tweak on top for fid-related file insertions. this would make it possible to grab any chunks of old files that the site admin wished for tracking by PIFT. if we don't want to make that script a part of this patch, that's fine. we can follow an upgrade procedure on d.o like this:

1. take the site down.
2. run cron to grab any files between the last cron run and the time the site was taken down.
3. upgrade the code and test it real quick
4. bring the site up

1. return array(); needed in update function
2. $files = _comment_upload_load_files($comment->cid); should be $files = _comment_upload_load_files($comment['cid']);
3. there's no $file->uid returned from _comment_upload_load_files(), which is needed in {pift_data}
4. if ($node->type == 'project_issue' && arg(0) == 'node' && is_numeric(arg(1))) { this conditional prevents 'insert' op from ever running in pift_server_nodeapi()
5. you're only using the issue-specific insert statement in pift_server_add_files(), if you'll look at the original function, the insert statements for original issues and for followups are different.

the last patch needed a fair amount of massaging to get everything working well. attached patch was well tested for both issues and followups, and has been committed to 5.x and HEAD.

and to complete this task, i've committed a fancy update script that allows site admins to grab already existing files and add them to the testing queue: http://drupal.org/cvs?commit=150769