Posted by bramick on October 6, 2009 at 6:44pm
| Project: | Webform |
| Version: | 7.x-3.9 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
In the Webform advanced settings, I'd like to see submissions by calendar week and month. It currently only does a count from last submission. It would be nice to be able to limit submissions for example by once a week, so it would calculate if you posted in week 1 of this month. If not then you can post anytime during that first week.
Maybe this is an additional module.
Comments
#1
I'm moving this conversation to this thread as suggested at http://drupal.org/node/488128. First, attached is the separate patch to add a simple monthly option and, while I'm at it, a simple yearly option.
To continue the discussion on how to handle more complicated date patterns for submission limits, what occurs to me is that I have found the Additional Validation and Additional Processing fields to be enormously useful for doing custom stuff.
Would it not be wiser to provide the unlimited and simple schedule options as they are now (adding the monthly and yearly options from the patch) and possibly add a 3rd radio button for custom php validation that disables/skips the simple schedule functions and leaves it to the existing php Additional Validation for more complex limits?
That way, it would be infinitely more flexible to use and considerably simpler to implement than trying to add gui calendar functions to the admin interface.
#2
Marking duplicates:
#327237: 1 entry per calendar day
#488128: Every hour calculation is wrong
#3
I have made a patch that I have tested on a webform that receives 40-50k submissions a month and several hundred a day. This patch dynamically calculates the 'expiration' date based on midnight the current day or midnight the first day (sunday) of the current week to allow a once per calendar day and once per calendar week submission limit accordingly. Please review and comment as necessary. This is something I have wanted to get into webform for quite awhile.
This patch seems to have been eaten...look below at #5
#4
Thanks leprechau! Unfortunately drupal.org seems to have eaten your attachment and I can't view it. Could you upload again?
#5
I just noticed that...here we go...try number two.
#6
My inclination here is to ditch the current day and week intervals, as they are misleading. Preferably, we should add an hook_update_x() function to change our database storage into something that makes more sense than timestamps (instead use strings hour, day, week, month, and ever).
#7
I would be all for ditching the current static timestamps. I am not sure though about changing the database. If you just stored strings in the database what would you use to track user submissions? I would think you would still have to use timestamps for 'hour' at least and it is pretty simple to calculate the calendar equivalent based off stored timestamps like I did in the patch above. However, I am guessing that you already have a better idea in mind for tracking submissions and calculating submission count without using timestamps. Let me know if there's another method you would like to use and I'll give it a shot.
#8
I think you could use your mktime() approach for anything, hours included. But otherwise it's trivial to say
if ($interval == 'hour') $interval = 3600;. We certainly don't need to store 3600 in the database. We'd still store the time users made their submissions of course, but we wouldn't store the submit_interval as a number of seconds any more. We'd convert it to a varchar and store a string representation of the interval.#9
Okay, I'm following. Sorry I got a little confused earlier I guess. I agree with you there is no need to store the actual submit_interval values. This would also get rid of the ugliness of the -1 hacks for 'ever' that I continued for the calendar days approach with -2 and -3. I'll look into changing that and creating an update hook for it. Other than that what do you think of the structure and logic after the database changes are made?
#10
Outside of the database changes, I'd like to see our logic simplified quite a bit. Right now you're doing the mktime() magic inside of case statements and doing the exact same thing in two different places (one in webform.submissions.inc and one in webform.module). These should be consolidated into a single location. I'm also not real keen on things like
if($timestamp <= $basetime + $range). It seems like you should be able to calculate the timestamp for "1 week ago" and compare that directly with $timestamp. Right now $range is not necessarily accurate (the length of a month differs from month to month for example, even though we don't have month support, I expect it should be easy to add). Lastly, we should be using gmdate() and gmtime() whenever possible, since it's standard practice to use gmtime() for timestamps stored in the database.#11
#12
Here's a consolidated approach to this, using the changes I suggested in #10. leprechau, if you can review it I'd be happy add this in, though we'll still need a Drupal 7 port.
#13
Heh, removed a few lingering dsm() calls.
#14
Here is a revised patch that adjusts the day of the week according to the site-wide setting for "first day of week", which will make it so users can decide what day their forms reset on a "weekly" basis.
#15
Sorry, I have been overloaded with some other projects lately and wasn't able to finish this up. What you have done looks really great. I like the changes for using the drupal settings and gmt based times along with the centralized timestamp calculation function. I am going to apply this today and I'll let you know if I get any negative feedback or complaints from users about it. It should go through a few thousand submissions over the next few days especially over the weekend.
Thank You!
#16
It seems the patch above was reverted in the beta5 release? The update hook 6316 was replaced and all of the code for calendar specific limits seems to have been removed. Was this intentional or a simple oversight?
#17
Here is a new patch for beta5 that also includes using the user's timezone setting before defaulting to the php.ini setting and finally UTC. I took this idea from the patch for the drupal7 get_user_timezone() function. I also fixed a %d vs %s for submit_interval in the webform update query. Comments and suggestions welcome as always.
#18
The patch has never been committed, I'm still waiting on feedback ;-)
When a patch is committed to the CVS repository it is marked "fixed", though it won't actually be available for most users until the next version comes out.
#19
Ohh, okay. That makes sense. I can confirm that it has been working well for me since I rolled it out. The GMT based reset was causing issues for some people that were expecting a 'midnight' reset so they could submit in the evening and then again the next morning. Other than that I have received pretty positive feedback from my user base on the true calendar day reset.
#20
This patch needs cleanup and a reroll. I'm still interested in adding it eventually.
#21
suscribed!
#22