Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Is there a solution to limit the number of submissions for a webform, in total not per user.
I'm using the webform as a volunteer sign-up sheet. And only can accept x number of people.
I want to be able to set on the form to only accept 10, 20, 100, etc. submissions and then lock.
Any ideas? If not I would like to kindly ask for a feature request.
Thanks,
Cameron
Comment | File | Size | Author |
---|---|---|---|
#44 | webform_limit_total_503264-d6.patch | 13.8 KB | quicksketch |
#44 | webform_limit_total_503264-d7.patch | 13.54 KB | quicksketch |
#42 | 503264-d6-5.patch | 12.93 KB | redndahead |
#42 | 503264-d7-6.patch | 12.62 KB | redndahead |
#40 | 503264-d7-4.patch | 12.37 KB | redndahead |
Comments
Comment #1
aichfeldjugend CreditAttribution: aichfeldjugend commentedare the volunteers all registered users?
or can anonymus users also sign up for whatever you use the webform?
in case 1: we need a developer
in case 2: enter the number of Submissions per User and set the access of the webform to "Anonymus User"
in hope that this will be useful
Comment #2
gintass CreditAttribution: gintass commentedcase 2 doesn't work (at least with the 6.2.9 version of the webform). I tested from my computer and it seemed to work, but when I opened registration to real users they were all coming from different computers with different IP addresses and they were still able register above the limit. Registrations didn't close automatically when the limit was reached. Only if everyone would use the same computer, above suggested "case 2" would work.
I found a better solution (php snippet) which does work:
http://drupal.org/node/342896
Comment #3
quicksketchMoving this to the 3.x version. This might be a good long-term feature to add, even though it's already possible to emulate this functionality with the Additional Processing code. See also #260989: Limiting the max number on a per form basis, not per user basis.
Comment #4
quicksketchComment #5
freakalis CreditAttribution: freakalis commentedI also need this feature because im using webform as a way of signing upp for an event. And the event has a limited number of seats.
I made this patch that adds a setting to webform settings if it should limit submissions per user or per total submissions.
I also has a new field (also at webform settings) where you can enter a custom messge if the the submission limit has been exceeded.
It needs two extra columns in the database to store this new info so I also made an update function to add these.
Comment #6
quicksketchThanks for the patch freakalis. Adding the total limit is great but the addition of a custom message when the limit is exceeded should probably be split out into a different issue. We don't provide any other customization of messages, and I'm not sure we should purely because of the number of messages that Webform outputs. If you'd like to customize the message, you can use String Overrides module or you can override the theme_webform_messages() function.
If you want to tackle customized messages, let's handle it in #279703: All response text should be configurable and keep this one focused on just adding the options to limit the total.
Comment #7
freakalis CreditAttribution: freakalis commentedI agree with you quicksketch. They are two separate issues. I have attached a new patch that just deals with the total submissions.
The reason i added the customizable limit text was because the default text says: You have submitted this form the maximum number.....
This is no longer true when it's the total submissions that counts. Better to say that the Form as been submitted this form the maximum number of.... etc
But also so you could have different limit texts for every form. Im using webform as a registration for events. If it become overbooked i would like to say something like, Please contact XXX to be on the reserve list or More slots will be available at XXX.
Comment #8
freakalis CreditAttribution: freakalis commentedAnd the patch :)
Comment #9
quicksketchLooks pretty good, though just because there isn't a customizable message, it does make sense to create a new message that makes more sense. Rather than "You have submitted the maximum number of entries", something like "This form has received the maximum number of entries.", since it's entirely likely that a user would get the message even if they'd not submitted anything at all.
This change will also cause problems:
We MUST show the form to anonymous users if the cache is enabled to avoid the following situation:
- Anonymous user submits the form (limit of 1 per user).
- The anonymous user then gets the "You have submitted the max" message. The form is not shown.
- If the page cache is enabled, the page may get cached with the form not shown.
- Other anonymous users visit the page, but cannot see the form because some other anonymous user made a submission.
Comment #10
freakalis CreditAttribution: freakalis commentedOkey, in the normal limit submissions the cache check should stay. But when the limit is per webform it should not care about the cache. Because we don't wan't to show the form if they aren't able to submit it. Then we would like to show the "This form has received the maximum number of entries." even for cached/anonymous users.
If someone increase the submission limit in the webform the old cache would be cleared. Or am I still missing something :)
Comment #11
quicksketchYep, sounds perfect.
Comment #12
freakalis CreditAttribution: freakalis commentedNew patch according to post 9-10.
New error message when using total submissions limit: This form has received the maximum number of entries.
Comment #13
malhadeff CreditAttribution: malhadeff commentedWe had a similar issue. Form users could select a particular time and date, but we could only allow 150 people to select each time and date. We dealt with it by using this in Validation (where "424" was the node id of the form and "18" was the cid of the form element and "150" was the maximum number of submissions for any particular value of the form). It gets the job done:
Comment #14
span CreditAttribution: span commentedThis looks very interesting indeed but the patch fails on the last beta version. Will this be implemented anytime soon? I'm afraid I can't contribute much due to lack of time.
Comment #15
quicksketchThis patch is pretty good but has some problems. The UI needs a bit of work too. Rather than using a checkbox for "Do not limit submissions per user. Limit by total submissions", it would make more sense to have this as a textfield. Since it's entirely common that there would be a limit of "1 submission per-user" AND "100 submissions total". With the current approach it's one or the other.
Comment #16
anonAlmost the same as #12, but this one if for 6.x-3.6
Comment #17
redonwhite CreditAttribution: redonwhite commentedThis patch seems to be working, but I have two remarks:
I think that many people here are using webforms for signups, so it's fair to move this to major priority, esp. given that it doesn't seem like a very big thing to implement?
Comment #18
redndahead CreditAttribution: redndahead commentedHere is a version that will limit the total number of submissions the same way as it does by user. If a user is in a form while the limit has been reached after the user submits the form it will tell them the limit was reached while they were filling out the form.
Comment #19
reaneyk CreditAttribution: reaneyk commentedsubscribe
Comment #20
goose2000 CreditAttribution: goose2000 commentedsubscribe
Where is the dev version? I can't find it on the module page?
Comment #21
quicksketch@goose2000: Click "View all releases" on the project page. Note that the dev version doesn't have this feature either, you have to apply the patch in #18 if you'd like to try it out.
Comment #22
goose2000 CreditAttribution: goose2000 commentedGotcha, thanks. I realize I need a different limit functionality though. I need a kind of select list where the options could have a limit set on them (sessions A,B,C). Each could be used up say 20 times. When 20 of A are submitted, that option is disabled or hidden. User would be forced to choose B or C.
Any thoughts on that? Probably should start a different issue ticket.
Comment #23
goose2000 CreditAttribution: goose2000 commentedI still can not find a version of 6.x-3.x-dev on the "view all releases page", MIA.
EDIT - found it here:
http://drupal.org/node/730872
Comment #24
quicksketchSuch complicated validation functionality sounds like it would be a better feature request for Webform validation than Webform itself, if they don't have a similar request already.
Comment #25
mdpenguin CreditAttribution: mdpenguin commentedSubscribe
Comment #26
span CreditAttribution: span commentedThere is now also a module that does this, http://www.drupal.org/project/webform_limit_submissions
We migrated our old patched webform to use this module instead. It is still a bit rough in the edges (code?) but seems to work fine.
For anyone interested, this was how we made the migration.
INSERT INTO webform_limit_submissions (nid, sid)
SELECT webform.nid, webform.submit_limit
FROM webform WHERE webform.submit_limit_total = 1
SELECT wls.nid, wls.sid, submissions
FROM webform_limit_submissions wls
LEFT JOIN webform w
ON w.nid = wls.nid
LEFT JOIN (SELECT wss.nid, COUNT(*) as submissions FROM webform_submissions wss GROUP BY nid) ws
ON wls.nid = ws.nid
In our migration we ran into a problem when updating webform from 6.x-3.6 to 6.x-3.11. For some reason the 'auto_save' field was never created in the webform table. This is another issue of course and I've seen it mentioned in the issue queue but do watch out if you are coming from an old version of Webform.
The symptoms of the problems where that when adding components to a webform they would be created in the DB but would not show up on screen. In turned out the form was never created in the webform table, probably due to missing the auto_save field. There was never any error messages though.
Comment #27
vernond CreditAttribution: vernond commented@span - I've done a bit of work with the webform_submission_limits module (see http://drupal.org/node/1225780) and would love it if you take a look and let me know what you think in that issue.
Comment #28
redndahead CreditAttribution: redndahead commentedI still think this could/should go in the webform module itself. Here is a re-roll of the patch in 18.
@quicksketch you think that this has a chance of going into webform? or do you think it's better left up to contrib?
Comment #29
redndahead CreditAttribution: redndahead commentedFixes white space that I thought I had already fixed. grr.
Comment #30
Lion.creek CreditAttribution: Lion.creek commentedHi, sorry for the stupid question. Where insert php code for validation? Thanks
Sorry I know
Comment #31
vernond CreditAttribution: vernond commentedPlease don't mix issues in one thread, rather open a new one. Better yet, first search to see if your question has been asked and answered before.
Webform no longer supports inserting php code as it used to. This is in line with a movement across all of Drupal to phase out such fields. You may either make use of the unsupported Webform PHP module (use at your own risk), Webform Validation module, or create your own custom module (see webform_hooks.php).
Comment #32
retiredpro CreditAttribution: retiredpro commented@redndahead. I applied your patch from #29 to the latest release of webform 6.x-3.14 from august 31 and I get the following error on the site.
Fatal error: Cannot redeclare webform_update_6329() (previously declared in /var/www/website.com/htdocs/sites/default/modules/webform/webform.install:1437) in /var/www/website.com/htdocs/sites/default/modules/webform/webform.install on line 1520
I used the latest stable release instead of the dev version because it was updated more recently. I also tried the latest dev version but I received the same error. Any ideas?
Comment #33
redndahead CreditAttribution: redndahead commentedYou need to make it one higher than the last update number in install.php. So right now the last update number is 6329. So in my patch it should be 6330.
Comment #34
retiredpro CreditAttribution: retiredpro commentedthanks for the quick reply, redndahead! that fixed it for me.
Comment #35
redndahead CreditAttribution: redndahead commentedHere is an updated patch for 6.x-3.x and also a patch for 7.x-3.x
Comment #36
redndahead CreditAttribution: redndahead commentedOf course what patch of mine would be complete without whitespace fixes.
Comment #37
quicksketchThis patch looks great! The only problem I see is that this segment is located in the wrong location:
Right now it's in webform_client_form_submit(), when it should be in webform_client_form_validate() with the other validation of the per-user limit check. Other than that, these look good to go.
Comment #38
quicksketchOh I'm also concerned about this change (technically an API change):
Really we shouldn't be making API changes like this mid-release-cycle. However it only affects Drupal 6 (D7 uses an array of arguments), and this function isn't often overridden afaik. I'd like to keep the change as-is for code-consistency, but I'm certain I'll get some flak from users in the future for it. So in advance of all the complaints: I'm sorry for breaking your theme overrides.
This change is an overall benefit that it is worth the change to me. Users will get an error upon upgrading when submitting a form that an argument is missing, so at least this won't be a silent problem.
Comment #39
redndahead CreditAttribution: redndahead commentedCan we check this before I do the d6 patch?
Comment #40
redndahead CreditAttribution: redndahead commentedForgot to delete the old code.
Comment #41
quicksketchLooks pretty good. In the existing code, we just let theme_webform_view_messages() print out the error message. Although your existing error message may be more descriptive, for consistency just reusing the same error message may be better. Also in the case of anonymous users, the limit may have been hit long before they even started filling out the form due to page caching.
We might also find a teeny performance gain by putting the "total" check before the "per-user" check, since it's more likely the the total limit will be hit before the per-user check (maybe... I'm just assuming here).
Comment #42
redndahead CreditAttribution: redndahead commentedHere are d7 and d6 patches with your suggestions.
Comment #43
redndahead CreditAttribution: redndahead commentedComment #44
quicksketchThanks @redndahead. I reviewed these and only found a few minor changes to be made:
- The total submission limit message wasn't working the D6 version of the patch (it was still using D7-syntax for calling theme functions with an array).
- There was a notice error when viewing forms of undefined variable $total_limit_exceeded.
- I moving the "total" limit above the "user" limit, as I think it makes more sense that way.
- I changed the text on the existing limit to differentiate it from the new limit. They now read:
Now that we have two options, I think that checkboxes might be more appropriate than radio buttons. Previously I'd used radio buttons to line up with the other available options. Now however, the "Unlimited" option is confusing when combined, such as "Unlimited" per-user submissions combined with "3 ever" total submissions, obviously the per-user limit isn't really "unlimited" any more. I'm sure users will figure out easily enough, but the text is misleading.
We also have a bit of cleanup to do after this patch to make our variables and function names make sense. I don't like
_webform_submission_limit_check()
being per-user, it should be renamed for consistency with_webform_total_submission_limit_check()
.Anyway, such cleanup tasks can be separate. This is good enough for inclusion.
Comment #45
quicksketchCommitted to both 3.x branches.
Comment #46
redndahead CreditAttribution: redndahead commented@quicksketch thanks!
Comment #48
nackie CreditAttribution: nackie commentedHi
I was checking out the patch at #44 and was wondering if there is a possibility to limit the submissions based on the date? So, say you have a date component on the webform and there's already been a submission for that specific date, it should not allow any further submissions. The limit per day won't work in this case, as you could be filling in forms for different dates.
Thanks
nackie
Comment #49
quicksketch@nackie Let's keep this feature request closed. I feel like your question may be a better request for http://drupal.org/project/webform_limit_submissions than the core Webform module.
Comment #50
quicksketchComment #51
nackie CreditAttribution: nackie commented@quicksketch - no problem, I'll post it there then.