[Tickets #2799] IMP_Fetchmail_imap defaults never apply

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=2799
-----------------------------------------------------------------------
 Ticket             | 2799
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | IMP_Fetchmail_imap defaults never apply
 Queue              | IMP
 Version            | HEAD
 State              | Assigned
 Priority           | 1. Low
 Type               | Bug
 Owners             | Horde Developers
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2005-10-25 14:30) wrote:

> 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.