#access of date_combo fields prevents validation
| Project: | Date |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
The symptom is that when a date_combo element has #access set to FALSE, the form never validates because "The To date must be greater than the From date."
I think that Drupal core could do a better job here, however I believe that there is an issue with the way date handles validation using #process and #post. The Drupal core problem is that when a FAPI element has #access set to FALSE, FAPI still calls all of the #process hooks. I chatted with chx about it, and his response was "why not". But the answer to "why not" is that form element implementers (such as date) rely on the process callbacks to setup lots of work, and if the element isn't accessibly then why are they doing that work?
Since we're not going to fix this in Drupal core today (and 5.x ever) there's still a problem with the date module. I suggest that in date_combo_process you just check for #access and return if it's 0. Patch is attached.
| Attachment | Size |
|---|---|
| access.patch | 464 bytes |
#1
Here's an updated patch the doesn't catch a form element without #access at all.
#2
Hmm... true, this is an issue. This is probably needed in D6, too, I imagine.
#3
OK, fixed. I'm trying think if there are other places this will be needed, but I can't come up with any right now. Thanks!
#4
Automatically closed -- issue fixed for 2 weeks with no activity.
#5
I'm not getting good results with this patch. When I set the #access attribute to TRUE, the value of the field is erased upon submission and I get the following notices:
# notice: Undefined index: #value in /home/kratib/www/d6/includes/form.inc on line 1052.# notice: Undefined index: #parents in /home/kratib/www/d6/includes/form.inc on line 1312.
# warning: array_shift() [function.array-shift]: The argument should be an array in /home/kratib/www/d6/includes/form.inc on line 1323.
# notice: Undefined offset: 0 in /home/kratib/www/d6/sites/all/modules/cck/content.module on line 1025.
# notice: Undefined offset: 0 in /home/kratib/www/d6/sites/all/modules/cck/content.module on line 1025.
However, if I move the code snippet to date_combo_validate() instead of date_combo_process(), these notices don't appear and the value is not lost. What I get instead is the behaviour of #403404: Default value set to 1000 years back when #access is FALSE.
#6
Also applies to latest D6 release. In my test scenario, moving the
#accesscheck todate_combo_validateresolves the problem and I don't get the 1000 years problem either.#7
I have the same issue as kratib. If I set
#access = FALSE, a previously existing value should be retained. Instead, it's clearing it. A scenario would be a user with lesser permissions editing a node that was created with someone with access to that particular field. In my case, I'm doing multistep forms in which the#accessis set toFALSEfor steps that do not contain that particular field, in which case the value is being dropped after submitting a different step. See #503158: array_shift() warning when using Date fields.What would the implications be of returning
$elementinstead of just returning nothing? The idea is to return$elementwithout processing it.<?phpif (isset($element['#access']) && empty($element['#access'])) {
return $element;
}
?>
This is what I'm doing to solve the issue with the Multistep module. The problem in #403404: Default value set to 1000 years back when #access is FALSE was also fixed for me, although I'm not sure if this is the correct approach.
#8
Here's the patch to make
date_combo_process()return an unprocessed$elementwhen#accessisFALSE.#9
The last patch did not apply successfully for the latest code. I'm uploading a new patch that works with the current development snapshot.
#10
Thanks vkareh - #9 is just what I needed :) Works perfectly.
#11
Yep, I think this is the right solution. Thanks!
#12
Automatically closed -- issue fixed for 2 weeks with no activity.