On 05/17/2013 04:07 PM, Simon B wrote:
On 17 May 2013 23:03, "Simon B"<simon.buongio...@gmail.com> wrote:
On 17 May 2013 22:51, "Michael M Slusarz"<slus...@horde.org> wrote:
Quoting Simon B<simon.buongio...@gmail.com>:
On 16 May 2013 19:38, Michael M Slusarz<slus...@horde.org> wrote:
Quoting Simon Brereton<simon.buongio...@gmail.com>:
On 10 April 2013 12:02, Simon Brereton<simon.buongio...@gmail.com>
wrote:
On 10 April 2013 11:39, Nuno Lopes<nuno.lo...@portugalmail.pt>
wrote:
Hi Simon,
from what I understand the funcionality hasn't gone away, it
has
been
moved to another configuration. You can read that in the upgrading
documentation:
The following spam-reporting options have been removed and can now
be
configured per-backend in ``config/backends.local.php``::
$conf['notspam']['email']
$conf['notspam']['email_format'] ...
https://github.com/horde/horde/blob/master/imp/docs/UPGRADING hope this
helps, -- Nuno Lopes
So I see. I'd still feel better knowing the rationale for these
changes.
Because it made zero sense to set a one-size-fits-all spam reporting
solution in the configuration file. What happens if you have two
servers
listed in backends.php, your local IMAP server and Gmail? I'm about
102%
sure that you do not want the same spam reporting configuration for
both of
these servers.
Not that my userbase uses this feature, but I can this will cause
some
confusion too..
The following options have been removed::
$conf['compose']['link_all_attachments']
So, I've added these configurations items to
imp/config/backends.local.php and still I have no report as spam
button in my mail interface anymore.
And you added them in the correct format, as described in
config/backends.php? You can't just copy/paste the old lines from
conf.php,
if that's what you did.
Interesting - the old way was of course much easier to configure :)
I would disagree. Previously, you may have had to configure in BOTH
conf.php and in a hook, depending on the backend. That is a confusing
configuration design. Now all configuration takes place in a single
location.
Just because it is less familiar doesn't mean it is not easy.
Innocent reporting is a little trickier. How does one move it back to
the Inbox? From the docs, I have:
Post-spam actions are a user-defined activity, so this is configured in
the preferences ('move_innocent_after_report').
How is it possible to go back to a version that has it?
If you already upgraded to IMP 6.1, hopefully you created a backup of
IMP
6.0.x you can revert to.
How does that work if you install via pear?
You could have cloned your installation. Or installed to a different
PEAR directory.
Oh, and I had a separate pear install - despite the install docs warning
that it's not recommended even if you do provide instructions for it - for
stage, and upgrading was a nightmare, which is why I moved to git.
Simon
These days, it really isn't the (potentially time-consuming)
responsibility of a software project anymore to support these kind of
"multiple-setups on a single machine", at least software projects that
don't have vast resources. VMs are so ubiquitous, cheap, and easy to setup
and they accomplish precisely this.
Maybe not, but a downgrade path would be nice. If, I discover a bug, in
apache or OpenOffice, I simple purge and reinstall (and by and large) my
settings and preferences remain intact.
You're saying, I have to create a virtual machine every time a new
version comes out (sorry, but I can only afford a 2gb/500gb/€50pm box, as
much as I would love a 32gb/1tb box). And how does the database work?
If there's a schema change from 6.0 to 6.1 (which there was), how do I
move the delta data back to 6.0? To my knowledge, there's no button in the
interface to downgrade a db schema...
Simon
Simon, give it a rest. If you need a button to back out a release then
you are in the wrong profession.
To avoid surprises like you have apparently received here is what you
should do in the future.
1. Pay $20/mo for a VM slice at Linode or your favorite VM provider
2. Configure an "alpha/beta" test server on this slice exactly like your
production server(s).
3. Point an MX for test.mydomain.com at it with email accounts for all
your staff (and sign up for a bunch of newsletters with those test
addresses to generate lots of traffic)
4. Import and test new releases on your alpha/beta test server BEFORE
pushing it to production.
Yeah, the little VM slice will be underpowered ($20/mo at Linode gets
you 1GB RAM), but that is what you want in a test machine...
And if there is a problem with a release, no big deal...all that is
affected will be your test site...just figure out the new config or send
a suggested patch or report how to reproduce a bug reliably and let the
developers fix it for you. And if a project takes a direction you don't
like, with Open Source you always have the option of using a good VCS
like Git to develop and maintain your own local changes and just merge
in upstream changes in all other areas.
--
Andy Dorman
--
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: imp-unsubscr...@lists.horde.org
