Start and End Dates Needed for Submissions Export

No it is not currently possible. I think it might be more feasible to have an option for "Export last [ x ] records", rather than "Export new records since last export", since for many sites there might be multiple people downloading the results and skipping entries would be very prone to error.

If you're using Webform for clients, I'd encourage you to write a patch to add this feature to Webform.

Subscribing, interested in exporting submissions.
greetings, Martijn

The 2.x version is no longer getting new features. This would still be a great feature to include in Webform if a patch were to be written. There are many other higher priorities though, so I wouldn't expect this in the near future (unless a patch was submitted of course).

subscribing

Some of our clients needed the ability to export submissions by date range, so I made a couple modifications to the module to make this possible.

* added 2 optional start/end parameters to webform_get_submissions, and modified the pager and submissions queries to use them
* added 2 form elements to webform_report.inc and altered the call to webform_get_submissions

*These patches only add this ability to the export, but the alterations to webform_get_submissions should make it easy to add to the other display methods.
*This only works if you supply both start and end dates, alter the conditional that calls db_query() in webform_get_submissions to fix. I've run out of time today.

As I noted in your original issue #717450: Start and End Dates Needed for Submissions Export, no new features are being added to 2.x, so this will need to be ported to 3.x to be included. The 3.x version actually already includes a mechanism for selecting only certain selections.

Thank you! This is exactly what I needed.

This still seems like a good idea to me, but we'll need it updated for the 3.x branches.

Hey pfahlr - thanks so much! I've taken all of your hard work and rehashed it a bit for 6.x-3.2 if anyone wants to give it a glance and see what they think.

This is a good idea, and I have to admit the patch works (though it didn't apply properly), but I'm left wondering whether we should use a date field instead of a text field for the date selection. "Enter a date in dd-mm-yyyy format" isn't very user-friendly... particularly to countries that don't think of dates in that order. Also, then FAPI would deal with the validation, and we wouldn't need the webform_results_download_form_validate() function.

FWIW, I re-rolled the patch so for 6.x-3.x-dev as of today.

Here's an updated patch against 3.7, which should work against -dev as well since it's fresh, but still needs work, just updating so it applies cleanly.

Sorry, I didn't notice until now there's been activity here. There's really no reason not to use a datefield that I can think of, I just quickly put this together since one of my co-workers needed to pull an export and I wanted prevent the furthering of the anti-drupal grumblings that were starting to infest the department.

I'm not sure if this has functionality has been added at some point, I couldn't find any other tickets related to this and I don't see it in the dev branch so I've made a patch that adds a date range (including time) to the download/export page.

This is my first drupal patch so any feedback would be appreciated :-)

The patch doesn't seem to work anymore with the latest stable nor dev branch. Which version did you patch it for? Thank you.

@oscarm22, looking by the dates of your post and the releases, I would think that this patch would be for 6.x-3.17, however towards the end of the patch it doesn't apply as it should. What version were you using, or does anyone have something that applies cleanly to a newer release?

An here we are 4 years later... now new features are only being added to the 7.x-4.x branch. I'm not at all opposed to this request, it's just low priority and there hasn't been a working patch since 2010.

Downloading the latest submissions is in 7.x-4.x

Added patch based on title of this issue and for 4.x version

@rudins - Thanks for the patch. In reading the patch (didn't try it), I see some issues:

1) The validation of the input assumes a specific date format, which needs to be more general. I haven't looked elsewhere in Drupal to see how this is typically done. The date and time component within webform use individual fields, so that doesn't apply. If the Date module is enabled, it might offer something.

2) I don't see consideration of the timezone, which I think is probably needed (not sure, haven't looked into it).

3) I'm not sure why the best default with be the current day (midnight in the past to a minute before midnight).

4) I'm pretty sure the dates are stored in seconds, so your default above is leaving out 1 minute every day.

5) If we implement the issue where first-save, first completed, and last edited dates are all saved, that would interact with this patch quite a bit. I guess you'd have to pick which of those three dates you wanted to use.

If we can get these address, and the patch tested by the community, I'd be happy to commit it.

This patch does not address any of @DanChadwick's comments above, but it does fix a mis-naming of fields in @rudins' patch (the error setting for the date range part of the download form) - start_date was referred to as start_time in places throwing a Notice and failing to validate the date range fields.

A personal best, I took pity on a 6-year-old feature request.

This patch takes the work of @rudins and @a.hover and addresses the issues in #19, plus the restructuring of the report query code, additional timestamps fields, and drush integration.

1. 'range_date' was added as an additional export range type.
2. It accepts a start date and end date. These have placeholders based upon the date-only short date format, but no default.
3. The end date is interpreted to mean 1 second before midnight, if no time is supplied.
4. The start and end date are validated as valid dates and the optional end must not be before the start.
5. The theme of the range fieldset was restyled slightly, merging the descriptions of the options into the titles of the options, for a cleaner look.
6. The export is based upon the submitted date, unless only completed submissions is requested, in which case it is by completion date. This avoids problems with skipping draft submissions.
7. The new drush command (example): drush wfx 41 --range-type=range-date --range-start=4/3/2015 --range-end="4/3/2015 1pm"
8. Rewrote some of the drush help for wfx.

Committed to 7.x-4.x and 8.x.