Edit existing submissions with date validation relative to completion date

I like a variation on 2 where relative dates for both start and end validate dates are relative to ... some date ... that isn't the current date.

There is another issue relating to what we call the submission date. There are three possible dates:

1) Date submission was first saved to the database (even if draft)
2) Date completed submission was first saved to the database (not as a draft)
3) Date the submission was last saved.

I *think* we are currently storing only 1). I think the right choice would be 2) -- the webform must be valid as of the date it was first completed, even it it isn't valid for when it was first saved as a draft or last updated.

So I think we need to finish #1763668: Submission date shows draft save date first. I'm happy to review and promptly commit patches for that issue and then this one. In other words, I agree with what you want and I'll help, but I don't currently have time to write either patch as I'm working on other webform issues. Unless of course you want to sponsor the feature. I prioritize paid feature requests.

+1 on this. Have bumped into this problem quite a bit when Webform admins need to update a submission that has dates entered based on constraints that are no longer valid to the date when the admin is updating. So thanks for bringing this to light.

In one scenario, a form has a Ticket on sale date that must be +3 weeks from the submission date. When the admin goes to edit the form and the ticket on sale data falls within the +3 weeks at the time of editing, the on sale date must be modified in order to save the form. We have numerous use cases for this problem that I'm sure the community is working around too. Thanks again!

It appears that @jazzitup doesn't plan to post a patch, which is too bad. Some funding would help. Otherwise I prioritize security issues, bugs, patches written by others, and feature requests that are personally interesting -- in that order. :)

LOL, that sounds about right on the prioritization. I have to agree with you Dan.

No longer blocked by related issue.

Wow. That was a lot harder than expected.

This patch:

1. Extends the API for _webform_render_COMPONENT() to pass the submission as an additional parameter. While this might be useful in general, the reason it's needed for this issue is because the submission contains the completion timestamp, which is needed to "understand" a relative start or stop validation date.
2. Adjusts the function declaration for the additional $submission argument (even though it isn't needed) for every core component: date, email, fieldset, file, grid, hidden, markup, number, pagebreak, select, textarea, textfield, and time. Any non-core components will continue to function without problems as PHP can pass an extra argument without warning. Yay (just this one time) for PHP.
3. The webform_component_invoke() call that calls each components _webform_render_COMPONENT function was adjusted to pass the submission. This call is in _webform_client_form_add_component(). The submission is available in the $form passed into this function, with one exception addressed below.
4. The views handler for submission data also calls _webform_client_form_add_component() in order to render the component. In this case, the $form was simulated by passing the submission in the simulated form. (views/webform_handler_field_submission_data.inc, function render()).
5. In the date component, the reference time, if any is passed from the render function to webform_expand_date where it is passed for the start and end date to webform_strtodate().
6. In webform.module, webform_strtodate() accepts an optional timestamp. Only when a reference timestamp is passed (i.e. the completion timestamp of an existing submission) does special processing happen. In the absense of a timezone or DateTime functions, the reference timestamp is passed to PHP strtotime(), which does not have user/system timestamp conversion ability. Otherwise, a DateTime for the UTC reference timestamp is created. That date/time is then converted to the desired timezone's local time. Then any hour/minute/second is discarded (i.e. set to midnight). This then sets the stage to apply whatever relative (or absolute) start or end date might be specified in the component. This is then formatted and used as the adjusted start/end date.

Phew. This feature cost me about $800 to implement. Funding would be appreciated.

Committed to 7.x-4.x for 4.8.

Needs port to D8.

Committed and pushed to 8.x-4.x. Thanks!

Unbelievable. Thanks Dan, you rock!

Unbelievable. Thanks Dan, you rock!

Fund the feature? If I don't get some funding soon, I won't be able to keep this up.