Submission date shows draft save date

Thanks, sounds like a valid bug report to me. I think we built-in some kind of protection to prevent submission times from being updated to the current time if the submission was edited by an administrator (or by the user at a later date). But I think you're right that the first time the "final" submission is completed, that should take on the submission date and replace the draft date. We don't keep multiple values for draft/submitted time, so I think this is a reasonable compromise.

I have the same problem with this behavior (which I suppose it is the result of this http://drupal.org/node/224299 ).

My users supply data for beaches for the Blue Flag award via a multi-page webform and they come back next year and update the forms with new data.
The project administrators review the forms and they may have to edit something on the applicants forms.

So the correct behavior for me would be the following:
1) the user of the form submitter should remain the same regardless of edits (origin of data)
2) the date should reflect the last edit/modification regardless of who did it (date of data)

It would be nice if we could track revisions of a submission but that I suspect would be the place to implement the form as a node type.

Hi All -

I have exactly the same problem, in 7.x-4.0-alpha9, ie the "submitted" date in the results table shows the date of the first draft, not the actual submission date (when they pressed the "submit" button).

Should I raise a new issue against 7.x-4.0-alpha9, or is this thread bump sufficient?

Thanks
Pete

I am changing this to 7.x-.4.0-beta1 to keep with tradition of fixing latest version first then porting. Meanwhile, what's happening with this issue? It's causing major complaints from many clients.

No updates here, if there were, it would have been posted. :P

That said, the fastest way to solve any problem is to do it yourself (or find someone who can). I always review the "needs review" and "reviewed and tested by the community" issues before every release, so having a patch that's available for review is the fastest way to get it into the project.

What should it do?

Current behavior:
Timestamp is allocated when the draft is first saved.

Suggested behavior:
Timestamp is allocated when the draft is first saved.
Every time the draft is edited, the timestamp is updated.
When the draft is submitted, the timestamp is updated.
The timestamp is not updated again, even if the submission is edited.

Is that what people want it to do?

This sounds reasonable to me.

The timestamp is not updated again, even if the submission is edited.

Actually for me this is the problem: that the submission can be edited without this being reflected in the timestamp.
In my opinion the timestamp should always reflect the last save (draft or submission).

I have had users calling for support believing they could not save the form (although they actually could) because they could not see the timestamp reflect their latest save.

Of course I understand there are other use cases where the aforementioned behaviour would be preferable.
So maybe it would be better to have some options on this?
Unfortunately I can not code so I can not help.

@arx-e - I personally don't think a subtle functional difference warrants creating a user option. Or one could go all-in and have both a creation and modification timestamp. But I would leave the spec as Liam prposed in #7. What you want can be easily achieve with a bit of custom code. It should not be more than 1-3 hours for someone experienced in Drupal development.

To be rigorous about this, there should be three time stamps: submission creation, time the submission was submitted, last edit of submission. Right now, we have only the first.

@Liam - Four? Time of last draft save.

Does anyone have the stomach for making some sort of user setting for the 2 or 3 options? I don't.

Last draft save would be the same as last edit. I think it would be better to track the various different timestamps then to allow changing when the timestamp is updated. The latter is too confusing and what do you do if someone wants to change it after the form is deployed?

Even as I am not a programmer I understand that my suggestion about selectable options is too complicated.
Plus unfortunately I do not currently have the budget to hire someone for this job.

If Liam's suggestion about 3 timestamps (or 2 as in plain files created/modified) is doable without introducing too much complexity I would vote for this approach.
If it is not I would vote for the timestamp to reflect the last edit/modification.

@Liam - I was joking, but there could be first first, last draft, first submit, last save.

So we could:

1) Save one thing, hardcoded what it is.
2) Save 2 or 3 things, hardcoded what they are.
3) Save one thing, chosen in the webform (and maybe unchangeable after there are submissions).

Last draft and last save might as well be the same. Another way to look at it would be to have create and modify, just like on a file system; add to that the submit date.

My suggestion would be to leave the code as is and create a documentation page for a tiny custom module that uses the Webform API to update the timestamp every time a webform is saved.

This would be consistent with the new API to allow multiple drafts (which come to think of it, could use a documentation page too).

The Webform Results tab currently has a column titled "Submitted". Given that title, the dates in that column should behave as described in #7 or be updated every time the submission is edited. Date of first draft is clearly wrong in my opinion. I would like to write a patch; I just need direction of which option to take.

Hi Liam,

Here's an idea. What if for each submission we track these dates/times:
creation (first time the submission was created, whether manual or automatic),
submitted (first time the submission was saved not as a draft)
saved (time of most recent save)

We replace the existing Results page with a view. The view can display whatever the user wants, with the default view displaying the submitted date.

We create additional tokens for the two new date/times.

This way we give the user the choice of what they want and we don't introduce any additional UI. Getting the results into a view would solve other issues (such as showing sid versus serial, for which there is an issue).

Thoughts?

Makes sense to me.

One result of this is that the field to hold the date the form was submitted can replace the current is_draft field. A null value would mean that the submission is a draft; a date would mean it is not a draft.

Field names for discussion:

created

Timestamp of when the submission was first created or draft first saved.

submitted

Timestamp of when the submission was first saved not as a draft.

modified

Timestamp of when the submission was last edited.

Problem: The "submitted" field already exists and refers to "created", above. From the perspective of API/schema stability, the "submitted" field should not change its meaning. However, I can't think of an obvious other name to use.

After reading the discussion, I think this is an enhancement, not a bug.

Anyone figure out a solution to this?

We have people enter information into a form on a daily basis, then submit it at the end of the week. It would be good to have the "Date submitted" work properly and show as Friday, rather than Monday (when the first draft was saved).

Thanks

Someone needs to push forward a proposal. The choices are a) installation can pick which date is stored or b) 2 dates are stored or c) 3 dates are stored.

Re 20:

How about:
submitted : first time saved as draft or submitted.
completed: first time submitted as complete
modified: date date saved.

I think the 3 dates approach is the best here as proposed in #20.
But since the change of name of an existing field is undesirable, the names proposed in #23 are OK with me.

If you think it is OK to use more than one words, the field names could be like this:

Submission first draft : first time saved as draft or submitted.
Submission completed: first time the button "Submit" was hit
Submission modified: last date saved.

And going one step further, maybe the button name could change from "Submit" to "Complete submission" or "Submission complete" to better indicate that your submission is moved from the "draft" state to the "complete" state.

@DanChadwick: I think those titles will work. I'll try to find time to to work on this.

I am not in favor of renaming the submit button.

Let's proceed with #23

Took pity on yet another old feature request.

This patch:

1) Adds schema for a completed column and modified column.
2) Updates existing databases to add these columns and set them for existing submissions.
3) Downloads completed and modified times.
4) Properly saves the completed and modified times.
5) Adds views support for completed and modified times.
6) Adds token support for completed and modified times, both in default format and a specified date/time format.

Committed to 7.x-4.x.

Thanks very much!

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

Nice work here Dan.

Thank you Dan for this great addition!

I just tested it in a local blank drupal installation by creating a webform and a view for the results.

I can confirm the "submitted" and "modified" fields work as expected.
When following the sequence DRAFT > SUBMIT > EDIT1 > EDIT2, everything works as expected.

1. When a user fills a form and hits the "save draft" button, the "submitted" and "modified" fields get an update and the "completed" is left blank.
2. If the user visits a draft and hits the "Submit" button, "completed" gets a value and "modified" gets an update.
3. If the user edits a submission and hits "Submit", "modified" gets an update and the other 2 remain unchanged.

But in the no-drafts senario SUBMIT > EDIT1 > EDIT2, the "completed" value remains blank on SUBMIT and actually reflects EDIT1 which I think is a bit confusing.
As I understand it, if a user has hit "Submit", that means he is has completed the submission (even if he later returns to edit).

Odd. I thought I tested that path.

Fix re #34 committed to 7.x-4.x and 8.x. Thanks, @arx-e.

Thanks again Dan!
I can confirm that #34 is fixed and that in the no-drafts senario SUBMIT > EDIT1 > EDIT2, now the "completed" value gets updated on SUBMIT.

I also tested on a copy of an existing site containing old submissions (3 webforms, 400 submissions each and one of them has more than 500 components, originally built in D6 and upgraded last Sept).

I can see the drafts got the SUBMITTED copied in MODIFIED field only and the COMPLETED left blank (as expected)

The completed submissions got a copy of the SUBMITTED value in COMPLETED and MODIFIED fields.
There only a slight issue here, namely that a submission that was first submitted in 2010 and re-edited multiple times now shows the 2010 date in the MODIFIED field which might be confusing.

Would you consider leaving the MODIFIED field blank for old submission?
In this way we would have no value at all instead of a wrong value in the modified field of old submissions.

Re #40. I don't think so, but that's not to say that you can't run whatever script you want. We have no idea when the submission was last edited. So the submission date is the best we can do. I think the code should be able to depend upon the modified timestamp always having a value.

OK, I understand.

I would also like to point that these new fields should be displayed by default:
1. in the "Submission information" section when a submission is viewed (especially the MODIFIED value after a new save)
2. in the 2 embedded views: Webform Results and Webform Submissions (I have modified them and they behave as expected).

I'm going to disagree re #42 on both points. The different between these three dates is of interest to a small, maybe even tiny, minority of users and therefore the current behavior shouldn't change. If this were really of a huge importance to lots of users, it would have been requested and implemented 10 years ago when webform was first created.

Once of the goals of webform is to maintain the simplest possible interface, offer the largest possible ability of developers to get what they want, and hides as best as possible the rest in theming and deeply-placed options.

The views are not really an issue since anyone can modify them.

But at my experience the information displayed after someone edits a webform is important. As I reported in #9, I have had users calling for support believing they could not save the form (although they actually could) because they could not see the timestamp reflect their latest save.
And so I would be glad to see the last modification timestamp displayed to the user when a webform is edited.

Anyway this is only my humble opinion, I can only thank you again for adding this feature.

As you probably know, that information can easily be displayed by overriding the submission information template.