Limit submission by Calendar Week and Month

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.

Marking duplicates:
#327237: 1 entry per calendar day
#488128: Every hour calculation is wrong

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

Thanks leprechau! Unfortunately drupal.org seems to have eaten your attachment and I can't view it. Could you upload again?

I just noticed that...here we go...try number two.

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).

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.

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.

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?

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.

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.

Heh, removed a few lingering dsm() calls.

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.

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!

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?

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.

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.

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.

This patch needs cleanup and a reroll. I'm still interested in adding it eventually.

suscribed!

Would I be wrong to say that this issue is still going on and there has been no answer to limiting the week and month of the date field? This issue has been going on for 2 years without an answer and would be great to see something come of this.

Any updates would help this issue move forward and we can get back on track to figuring this out.

@ShawnRisk: this thread goes around limiting the submissions that users may make on a form. Your query around the date field is probably more pertinent to this issue: http://drupal.org/node/1429542#comment-5563106

Would I be wrong to say that this issue is still going on and there has been no answer to limiting the week and month of the date field? This issue has been going on for 2 years without an answer and would be great to see something come of this.

Well I wouldn't say there's not an "answer". @leprechau rolled an original patch that looked pretty good, I updated it a couple of times and it almost was ready to go. Unfortunately it fell off the radar and now is out of date. The patch needs to be updated (and ported to Drupal 7).

As I said above, I think this would be reasonable functionality for Webform to provide by default. If the patch gets updated I'll take another review at it.

Here is a patch for the 7.x-3.x branch that uses much of leprechau and quicksketch's original work, but also adds a configuration option in the webform for whether it should use relative time intervals (current functionality) or absolute time intervals (functionality of the patch) with an option to select the timezone (my use-case sometimes requires the site timezone and sometimes the users timezone).

Also, my opinion of the switch from seconds to strings in the submit_interval field is that doing so makes it more difficult/impossible for a site-builder or another module to add more options to the dropdowns. With the values being in seconds all they have to do is implement a form_alter hook and add additional options with the right number of seconds. If they were strings and we wanted to allow that, we'd have to add a hook to _webform_submission_interval_timestamp.

With the values being in seconds all they have to do is implement a form_alter hook and add additional options with the right number of seconds.

If minutes and seconds were added, would that eliminate the need for any possible alternatives? There's no need for an option like "2 weeks" or something, because you can already specify the number of intervals in the UI. And even if a contrib module *did* add a new time interval (like "moon cycle" or something), it wouldn't be supported by the absolute date formats. I don't think this is something we need to worry about.

with an option to select the timezone (my use-case sometimes requires the site timezone and sometimes the users timezone).

I'm not sure this is a good option to add, no one ever understands timezone settings do regarding user time vs. site-time. If truly needed, I'd prefer this was made available via the API instead of being a user-facing option.

but also adds a configuration option in the webform for whether it should use relative time intervals (current functionality)

I don't think this is a necessary option to add either. If you wanted to make it be a "relative" date, you can just use the smaller denomination and specify more of them. For example use a "24 hour" interval instead of a "1 day" interval. Again, if minutes and seconds were added, you'd be able to do pretty much any time interval using the more granular options.

If you wanted to make it be a "relative" date, you can just use the smaller denomination and specify more of them. For example use a "24 hour" interval instead of a "1 day" interval.

Sorry I don't know what I was thinking. This isn't the case. Our current option read as such:

Limit to [    5] total submission(s) [ every hour ]

Somehow I thought it was:

Limit to [    5] total submission(s) every [ 1] [ hour(s) ]

*If* we made the settings form work like that, it would eliminate the need for a relative vs. absolute setting. I think that would be a better approach to pursue than the relative/absolute option.

Back to needs work, per #27 and #28. I'd be okay with #17's approach (just switch everything to use calendar weeks/months) or #28's suggested approach. But either way this needs updating for 4.x. Someday we'll get this functionality.

Despite the long history of this issue, there hasn't been any progress or demand in the last couple of years. At this point, my inclination would be to add some sort of API and let the programmer decide if the period is up. If that is desired, please open a new issue with a patch and reference this issue.