[dev] Re: [imp] whitelist patch...

[Jan Schneider]

Quoting Amith Varghese <amith at xalan.com>:

> > No, no constants. The error code would be a Notification class -
> > 'horde.success', 'horde.error', 'horde.message', or 'horde.warning'.
> 
> I've fixed it so that sam uses Notification objects to report success or
> failure.  The code now returns a horde.warning if the user is already in
> the
> blacklist/whitelist.  The code also prevents duplicates from being added
> (if you
> select more than one message with the same sender from the mailbox view
> and add
> that to a blacklist/whitelist it will add the first occurrence and warn
> on the
> others).

That's not quite the correct solution, and I can't imagine this was what
Chuck had in mind.
API methods should never use the $notification object itself but always
return a PEAR_Error. The problem with the current code is not that it
returns an error object but that it is inconsistent and stops after the
first failing address.
 
> Ingo should be updated to do the same thing as sam because IMP no longer
> reports
> that the address was added to the blacklist (not that it was working
> correctly
> in the first place)

As we're discussing the IMP/black-/whitelist interaction here: I'm not sure
anymore if it's a good idea to redirect to the black/whitelist screen after
submitting addresses. Sure it's the only way to correct any accidently
submitted address or to finetune them. But now that not only IMP provides
this feature, it's hard to get back to the original screen, once you are in
Sam or Ingo.

What I used to do with IMP's blacklist was to click on "apply filter" after
I blacklisted addresses so that I get back to the last mailbox _and_ the
blacklisted mails get removed. Neither of these is possible if Sam or Ingo
are providing the blacklist backend.

Any ideas how to solve this issue?

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft