Just a quick request, would it be possible to add an option to the date component that adds a validator such that only dates in the future or past are allowed? Something like a list of checkboxes for:
[ ] Disallow past dates
[ ] Disallow present date
[ ] Disallow future dates
Disallowing future dates is useful for for instance birthdates, disallowing future days is useful for instance for making appointments. The present date checkbox should not be difficult to add when the previous two are there, and releaves the maintainer of webform of the burden of chosing if the present date should be included in the past, future or in none of them.
Thanks a lot in advance! (I would create a patch myself if I had time)
Comment | File | Size | Author |
---|---|---|---|
#19 | webform_date_limits-d6.patch | 10.9 KB | quicksketch |
#19 | webform_date_limits-d7.patch | 10.99 KB | quicksketch |
#18 | webform_date_limits-d6.patch | 10.78 KB | quicksketch |
#14 | webform-301949.patch | 4.77 KB | ice5nake |
#13 | webform-max_min_date_and_inline-301949_775526.patch | 6.31 KB | ice5nake |
Comments
Comment #1
Jorrit CreditAttribution: Jorrit commentedCan I please use the credits I earned by providing patches for #294013: Date not in email results and #285554: Grid component adds non-safe data to database to get this one done ? :)
Comment #2
quicksketch:D
I'll look into it.
This generally fits into several other requests also, where we need to have a way to provide ready-baked validation functions to many component types. For this purpose, I think I'd probably revise your suggestion to have an option like this:
Only allow dates between [ start ] and [ end ]
Where start and end textfields could use the dynamic values such as "today" and "next week", just the way that the default value field work. So "future" dates would be between "today" and no end value. Previous dates would be between no start value and ending "yesterday".
Comment #3
Jorrit CreditAttribution: Jorrit commentedThat's a good idea. You could use the strtotime syntax for that, although in this way non-english people have to use english terms.
Comment #4
quicksketchMarked #553008: Date field: prevent dates prior to current date as duplicate.
Comment #5
quicksketchMarked #741038: GNU Dates for Year Range as duplicate.
Comment #6
Scott M. Sanders CreditAttribution: Scott M. Sanders commentedSubscribing.
Comment #7
neokrish CreditAttribution: neokrish commentedsubscribing
Comment #8
ice5nake CreditAttribution: ice5nake commentedI've changed the title to be broader and utilize existing jQuery UI functionality. See http://jqueryui.com/demos/datepicker/#min-max
Currently Webforms uses date_popup_load, http://api.lullabot.com/date_popup_load. I don't think date_popup_load is sufficient.
This patch adds the minimum option allegedly #998544: Minimum value setting for date fields which is what I really need myself but it patches 3.4. Not sure if the patch works with the current version; I'd guess no.
There seems to be a good bit of chatter for this so I am upping the priority.
Comment #9
quicksketchI'll include datepicker fixes if/when this issue is corrected, I think the previous title is more accurate, since not all sites use datepicker. Webform already includes a lot of code to make the jQuery UI datepicker match webform configuration such as the year-range restriction.
Comment #10
ice5nake CreditAttribution: ice5nake commented@quicksketch, thanks for the quick replay. Although I feel the original title implies it will not fix my issue.
I need to restrict the first available date to two weeks in the future.
I may try to merge the patch here #998544: Minimum value setting for date fields with the current dev version if @koshea doesn't respond to my comment on #998544 soon.
Comment #11
ice5nake CreditAttribution: ice5nake commentedI modified the patch here #998544: Minimum value setting for date fields to work with the current dev version of the module. I didn't add a maximum date option but it probably wouldn't be too hard to do so.
Comment #12
ice5nake CreditAttribution: ice5nake commentedThe attached patch that includes the maximum and minimum date options.
It's a little messy because the patch includes work towards http://drupal.org/node/775526#comment-4454726
If someone could clean it up that would be great. If not maybe I will get back to it but I am not sure when I will have time. Therefor I want to share the patch in the meantime.
Comment #13
ice5nake CreditAttribution: ice5nake commentedNew patch. Removed drupal_set_message debug alert. Sorry
Comment #14
ice5nake CreditAttribution: ice5nake commentedOK. So I cleaned this up. This patch shouldn't have any code for issue 775526. It is based off of the current 6.x-3.x branch. My desire to no longer do merges when there was a release motivated me to get this patch acceptable. Hopefully I succeeded.
quicksketch, Let me know.
I probably won't be able to get around to finishing the inline code anytime as I decided not to use it. Hopefully my other patch will help someone get started.
Comment #15
ice5nake CreditAttribution: ice5nake commentedLet me know if there is anything I can do to get this patch moved into the project.
Comment #16
quicksketchThanks ice5nake. The patch looks great aside from a few things that could speed this along:
- The settings for year_start and year_end are now redundant with date_min and date_max. We should both remove these settings from the interface and migrate the existing settings over to date_min and date_max (through an update.php function).
- Setting a default date_min of "-2 years" and default date_max of "+2 years" would be a good set of defaults, line up with our current defaults, and encourage users to adjust the date span as needed.
- All tabs need to be replaced with two spaces in this patch (http://drupal.org/coding-standards).
Comment #17
quicksketchAlso the code for inline calendar handling needs to be completely removed, especially this debugging section:
Comment #18
quicksketchHere's an updated patch that could use some testing to ensure that everything works. It makes the suggestions I'd suggested in #16, including an update hook to migrate the old year settings into generic date settings. Obviously still needs a D7 port too.
Comment #19
quicksketchI've updated this patch for Drupal 7 and committed to the 3.x versions of the project. Please let me know if you experience any issues.
Comment #21
WiredEscape CreditAttribution: WiredEscape commentedIn my case I need date start to be a minimum of two business days in future with ability to omit Saturday and/or Sunday. This would prevent user from requesting appointment on unavailable dates and dates that do not allow time for confirmation.
Example to block out Sat & Sun:
Submit Date --> Start Date
Monday --> Wednesday
Tuesday --> Thursday
Wednesday --> Friday
Thursday --> Monday
Friday --> Tuesday
Saturday --> Tuesday
Sunday --> Tuesday
Example to block out Sunday only:
Submit Date Start Date
Monday --> Wednesday
Tuesday --> Thursday
Wednesday --> Friday
Thursday --> Saturday
Friday --> Monday
Saturday --> Tuesday
Sunday --> Tuesday
Two questions:
1) how to configure present patch for two day future start date?
2) Your thoughts on how to allow for omitting Saturday & Sunday?
Comment #22
ice5nake CreditAttribution: ice5nake commented@WiredEscape you should be able to set the start date to "+2 days".
Omitting weekends sounds like a separate feature request, cause I don't think you can do that currently.
Comment #23
quicksketchThis patch caused a break in the existing simpletests, which was fixed in the #1078750: Options for "- Select -" or "- None -" not automatically added issue.
Regarding weekends, see the separate issue at #1217370: Date - allow weekdays only.