Tickets :: Comment on [#2799] IMP_Fetchmail

* Your Email Address
* Spam protection	Enter the letters below: .___. .. .. . . [__ \|\/\|\|__\|\| \| \| [___\| \|\| \|\|___\|__\|
Comment	>> but these values never apply because imp/fetchmailprefs.php > >> unconditionally sets all parameters: > >> > >> foreach ($fetchmail->getParameterList() as $val) { > >> $fm_account->setValue($val, Util::getFormData('fm_' . $val), > >> $to_edit); > >> } > >> > >> so they wind up being empty strings (""). > > > > Well, if we're going to keep the defaults, we should make them show > up in the UI somehow. Possibly by having $fm_account->getValue() > return the default if the $account key is null; then it's just a > matter of finding a nice way for $fm_account to get its default > values - I looked at the code some and it wasn't falling in to pace > for me. > > > >> Should IMP_Fetchmail_imap() override empty strings with the defaults? > >> Does having an empty value for {l,r}mailbox make any sense (IOW, do > >> any remote servers interpret this as a sane default)? > > > > Probably not, but I'd be wary of running into a case (maybe with a > parameter that hasn't been added yet, even) where there's a non-empty > default for a parameter that can validly be empty. We don't want to > make it impossible for users to zero out parameters that can be empty. > > > > Moving the whole fetchmail form to use Horde_Form would actually take > care of all of this.
Attachment
Watch this ticket