Summary | Driver for Postfix in virtual SQL setup |
Queue | Vacation |
Queue Version | 3.0.1 |
Type | Enhancement |
State | Rejected |
Priority | 2. Medium |
Owners | Horde Developers (at) |
Requester | ralph (at) rsrc (dot) de |
Created | 10/23/2008 (6102 days ago) |
Due | |
Updated | 01/19/2015 (3823 days ago) |
Assigned | 12/15/2008 (6049 days ago) |
Resolved | 01/19/2015 (3823 days ago) |
Milestone | |
Patch | Yes |
State ⇒ Rejected
absorbed by ingo.
SQL users setup.
Some cleanup, some SQL query escaping for reliability
Assigned to
New Attachment: customsql.tar.gz
New Attachment: customsql.zip
Adds optional 2nd query to set and unset vacation.
Adds \R expansion for domain name.
FIXME:
domain name retrival and storage in $this->_domain probably not correct.
Alas, I'm no PHP coder.
extended too in order to load the module within module code and
config data.
I'll try and find the time to consolidate code between them as much
as possible.
extended too in order to load the module within module code and
config data.
I'll try and find the time to consolidate code between them as much as
possible.
in a generic fashion, wouldn't your driver only have to provide the
postfix/whatever specific queries?
extended too in order to load the module within module code and config
data.
As said: my intention was to have a gui for my driver where the user
can enter table/field names not just raw sql queries.
Imo it would be nice to have both:
a customsql driver which could to more than one sql querie and a
dedicated postfixsql driver.
a generic fashion, wouldn't your driver only have to provide the
postfix/whatever specific queries? Why would it have to duplicate the
same query code?
sql driver, and thereby avoid most code duplication?
unchanged is connect. Therefore not much code dulpication would be
avoided.
State ⇒ Feedback
sql driver, and thereby avoid most code duplication? I'm a bit out of
the loop on virtual mail user setups, but if postfix + sql is one of
the most common ones, then I agree making it easy to set up would be
good, especially if it doesn't introduce a ton of duplicate code.
postfixsql driver and an enhanced customsql driver that could issue
two sql queries.
If I were a Postfix admin and could choose between
a) easily configure my postfixsql driver via the config web interface
by just entering table and field names or
b) drill down naked sql queries
...I'd choose a) hands down. Even if I were capable of doing b). And
consider: some aren't.
Anyhow: I'll write that enhancement for the customsql driver next
week. Then why not let the users decide?
State ⇒ Rejected
http://www.supported.de/howto-mainmenu-8/32-horde-vacation-driver-for-postfix-virtual-sql-user-setup
HTH
began with at first.
But providing a dedicated solution for one of the most widely deployed
mail setups around was a obvious choice. Whats your argument against
providing that?
-Ralph
New Attachment: Horde-Vacation-Postfix-virtual-SQL-Driver.tgz
SQL users setup.
Some cleanup, some SQL query escaping for reliability.
State ⇒ Feedback
querie to activate vacation but for a Postfix virtual user setup you
need _two_.
Your customsql driver is _not_ capable of supporting a Postfix setup
with virtual users.
-Ralph
State ⇒ Rejected
Priority ⇒ 2. Medium
State ⇒ New
New Attachment: patch-postfix-virtual-SQL.tgz
Patch ⇒ Yes
Milestone ⇒
Queue ⇒ Vacation
Summary ⇒ Driver for Postfix in virtual SQL setup
Type ⇒ Enhancement
SQL users setup. It's agains FRAMEWORK_3 from CVS.
I started with customsql from CVS, but as said here:
http://thread.gmane.org/gmane.comp.horde.sork/2531
...for a Postfix autoreply setup the activation/deactivation must
execute two SQL statements.
This drivers now takes all necessary SQL tables and fields from the
Horde vacation online config and does build its SQL queries accordingly.
What do you think?