It seems that the date field does not use the standard Forms API way of setting a field to be required. This makes it hard for other modules to modify that attribute. For example the modules dependent and conditional fields allow to make the appearance of a widget depend on a certain value being selected in a select list. If the widget is set to "Required", mentioned modules are smart enough to drop the requirement in case the dependency is not met (by setting '#required' to false
and adding an additional validation function).
To reproduce:
- Install CCK, Date and Conditional Field.
- Create a content type with a select list (with entries "one" and "two") and a "required" date field.
- Configure the date field to depend on the select field being set to "one".
- Go to the form to add a node of the created type.
- Select "two" from the select list.
- Submit the form.
Expected bahaviour: The node is saved
Actual behaviour: An error is shown, saying that the date field is required.
Comment | File | Size | Author |
---|---|---|---|
#24 | drupal-date-required.diff | 552 bytes | mschuster91 |
#21 | date-popup-missing-required-20150618.patch | 631 bytes | bceyssens |
#12 | date-select-301538-12.patch | 761 bytes | peteruithoven |
Comments
Comment #1
arlinsandbulte CreditAttribution: arlinsandbulte commentedYes, the functionality provided by conditional fields sounds great.
But, I think this is more of a 'feature request' than a 'bug.' (even if it better follows standard coding procedures).
Marking as 'feature request' and moving to HEAD.
Comment #2
KarenS CreditAttribution: KarenS commentedThis is much harder than it sounds. Each date field is in fact a collection of sub-fields, and if there is both a 'From' and a 'To' date, it is *two* collections of sub-fields. Each of the sub-fields has to know whether or not that particular sub-field is required, which depends on how it is used (is it in a 'To' date? Is the 'To' date optional or required? Is there a value in the 'From' date? etc etc). So 'required' is a complex concept with dates.
So there is no easy way to do do this.
Comment #3
cdale CreditAttribution: cdale commentedI'm confused. I had a look at the logic used in date_combo_process() to set the required property on the field, and it looks identical to the logic used by CCK when it sets up the initial field.
To test, I simply made required equal the required setting on element, and everything appears to be fine.
Am I missing something? I understand that each field is made up of individual sub-fields, but surely the top level #required property should be indicative of what should be set on the actual fields themselves.
Comment #4
johnwarde CreditAttribution: johnwarde commentedHi,
Has this issue being fixed in a patch/dev?
I am new to Drupal, however I have a requirement on a project would require this issue to be fixed/implemented.
Thanks,
John
Comment #5
arlinsandbulte CreditAttribution: arlinsandbulte commentedDate 7.x-1.x is unsupported.
This issue should be verified in the latest version of Date (7.x-2.x-dev) and re-opened if still valid.
Thanks
Comment #6
zilverdistel CreditAttribution: zilverdistel commentedI followed the steps to reproduce, as stated in the issue description:
Module versions used:
I came upon this issue because of issues I had with the date field when used in a field_collection. The steps to reproduce my case:
I expected an error message that the (second) date field is required.
I tested this same scenario with a field collection without date fields (a text and a term reference field), and did not have this issue (the error for the second field collection showed up).
Also: for date fields in a field collection, the required *star* doesn't show up.
Comment #7
zilverdistel CreditAttribution: zilverdistel commentedComment #8
zilverdistel CreditAttribution: zilverdistel commentedThere's a patch that fixes the appearance of the "star": http://drupal.org/node/1248786#comment-5896840.
Still not validating my dates in the field collections. An empty date value in the first field collection doesn't validate, as expected. But an empty date value in the second or latter collections doesn't keep the form from saving .. not getting the validation errors I expected.
Comment #9
attiks CreditAttribution: attiks commentedClientside_validation is also affected, we depend on the use of #required to bind our rules, in the case of a date_select and with the option 'no default value' #required is set only on the parent. see #1669570-2: Date field validation
My 2c:
If a date field is required and rendered using select elements, it means that each of those select elements is #required is well, how this will be themed is something else.
Comment #10
josebc CreditAttribution: josebc commentedim having he same problem with clientside validation without field collection
Comment #11
junedkazi CreditAttribution: junedkazi commentedJust changed the #required for the select date element
Comment #12
peteruithoven CreditAttribution: peteruithoven commentedI'm resubmitting the patch. Simpletest hickup ?
Comment #13
Elijah LynnSam Boyer (sdboyer) found out from Jeremy Thorson (jthorson) that the above patches are postponed because the 7.x.2.x-dev branch is failing/not passing --> http://qa.drupal.org/pifr/test/200603
According to Jeremy, co-maintainer of Drupal's automated testing infrastructure, a failing branch is the only thing that could/should result in endless postponement.
Comment #14
grossmann CreditAttribution: grossmann commentedI tried the patch but it doesn't change anything for me. The class is not added to the field.
I think I need this to get VBO to work correctly with required date fields (#1808604: "Modify entity values" not setting #required => FALSE for hidden *Date* fields).
Comment #15
Cellar Door CreditAttribution: Cellar Door commentedI can confirm that the patch in 12 works for my scenario. Using editable fields the date selection was not rendering required causing pdo exceptions when it went to insert the malformed date into the database.
Such a small patch so such a large module. Anyone else able to test? I'd say it should be marked RTBC.
Thanks a ton junedkazi!!!
Comment #16
griz CreditAttribution: griz commentedPatch in #12 didn't work for me. Until I added a default value to my date fields VBO was broken.
Looks like I will empty the form elements with javascript on page load since I have to do some messing around there anyway.
Comment #17
webkarthik CreditAttribution: webkarthik commentedI am new to this community and I am not sure if this is the right place to provide an alternate solution. The below code on theme's template.php also solves the problem
Replace,
|NAME OF YOUR THEME| with name of your theme
|FORM ID| with id of your form
|MACHINE NAME OF REQUIRED FIELD| with machine name of your date field
Comment #18
podarokdue to #16 this needs work
Comment #19
delacosta456 CreditAttribution: delacosta456 commentedhi
i know this thread is old and don't know if i am right but this may be a possible solution i will like to share.
I was facing this problem too with the described "to reproduce method" explain above. i even install Field Validation module to see whether the server side will work but no chance.
I then decided to abandon server side validation for client side validation by downloading, intalling and enabling the Clientside Validation Module and forgot to disable the Field Validation module i tested before while testing the Clientside Validation Module freshly enabled.
i was suprise the see that while testing client side module, error rule i created before with the Field validation module , started working.
So in conclusion with the tow module enable , this issue can be temporally fixed, until a great and working patch been created.
Comment #20
bceyssensSame bug exists in the date_popup sub module
Comment #21
bceyssensPrevious patch had wrong paths
Comment #22
andriyun CreditAttribution: andriyun as a volunteer commentedComment #24
mschuster91 CreditAttribution: mschuster91 commentedAttached patch checks for required attribute and barks with the standard Drupal error message when the field is empty.
Comment #25
max-kuzomko CreditAttribution: max-kuzomko commentedComment #26
max-kuzomko CreditAttribution: max-kuzomko at Smartweb commentedHi guys,
I can't reproduce this one anymore. However there are some comments:
This item doesn't specify a field type (date, date ISO, date UNIX timestamp). I tested all of these field types: date, date ISO, date UNIX timestamp
doesn't specify a type of dependency (visible, invisible, required and so on). So I created the following dependencies: Date/Date ISO/Date UNIX timestamp is visible when Select field has value "one".
I got the expected behaviour:
Regarding the patch #23.
Should we create a new issue for #23?
As this is the path for date_popup module, If I'm not wrong.
Comment #27
max-kuzomko CreditAttribution: max-kuzomko at Smartweb commentedComment #29
max-kuzomko CreditAttribution: max-kuzomko at Smartweb commentedComment #30
hamrant CreditAttribution: hamrant at DEWEB Studio commentedThe same could not reproduce, tested on CCK 7.x-3.0-alpha3, Date 7.x-2.8, Conditional Fields 7.x-3.0-alpha1.
Settings for Conditional Fields:
Dependent - Date (field_date)
Dependees - Select (field_select)
Description - Date is visible when Select has value "one".
Comment #31
hamrant CreditAttribution: hamrant at DEWEB Studio commentedComment #32
max-kuzomko CreditAttribution: max-kuzomko at Smartweb commented