postfixadmin-tracker Mailing List for PostfixAdmin (Page 12)
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(67) |
Nov
(83) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(57) |
Feb
(15) |
Mar
(21) |
Apr
(38) |
May
(27) |
Jun
(38) |
Jul
(35) |
Aug
(50) |
Sep
(8) |
Oct
(9) |
Nov
(59) |
Dec
(59) |
| 2009 |
Jan
(27) |
Feb
(42) |
Mar
(63) |
Apr
(46) |
May
(26) |
Jun
(25) |
Jul
(40) |
Aug
(19) |
Sep
(17) |
Oct
(35) |
Nov
(26) |
Dec
(21) |
| 2010 |
Jan
(11) |
Feb
(19) |
Mar
(40) |
Apr
(25) |
May
(23) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(21) |
Oct
(12) |
Nov
(10) |
Dec
(22) |
| 2011 |
Jan
(30) |
Feb
(23) |
Mar
(23) |
Apr
(38) |
May
(32) |
Jun
(19) |
Jul
(20) |
Aug
(36) |
Sep
(11) |
Oct
(28) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(3) |
Mar
(16) |
Apr
(28) |
May
(29) |
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(7) |
Mar
(29) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(8) |
Aug
(5) |
Sep
(5) |
Oct
(4) |
Nov
(27) |
Dec
(81) |
| 2014 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
|
May
(41) |
Jun
(16) |
Jul
(7) |
Aug
(10) |
Sep
(24) |
Oct
(50) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(7) |
Apr
(20) |
May
(1) |
Jun
(3) |
Jul
(12) |
Aug
(1) |
Sep
(17) |
Oct
(5) |
Nov
(20) |
Dec
(10) |
| 2016 |
Jan
(10) |
Feb
(11) |
Mar
(22) |
Apr
(30) |
May
(33) |
Jun
(3) |
Jul
|
Aug
(12) |
Sep
(20) |
Oct
(11) |
Nov
(15) |
Dec
(8) |
| 2017 |
Jan
(1) |
Feb
(11) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-06-20 12:51:50
|
Bugs item #3086890, was opened at 2010-10-13 20:18 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3086890&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Vacation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Johan Meiring (jmeiring) Assigned to: Nobody/Anonymous (nobody) Summary: vacation.pl does not log to mail facility when using syslog Initial Comment: vacation.pl does not seem to use the 'mail' facility when using syslog. It seems related to the word "Facility" starting with a capital F. The following patch fixes it: mailhost:/var/spool/vacation# diff -u vacation.pl.orig vacation.pl --- vacation.pl.orig 2010-10-13 22:12:03.000000000 +0200 +++ vacation.pl 2010-10-13 22:14:32.000000000 +0200 @@ -214,7 +214,7 @@ if($syslog == 1) { my $syslog_appender = Log::Log4perl::Appender->new( 'Log::Dispatch::Syslog', - Facility => 'mail', + facility => 'mail', ); $logger->add_appender($syslog_appender); } ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2011-06-20 12:51 Message: Thanks; change applied to svn. See revision 1073. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2011-06-20 12:51 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: maharaja (maharaja) Date: 2011-06-20 12:32 Message: i can confirm this on debian 6.0 using liblog-log4perl-perl 1.29-1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3086890&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-20 12:38:48
|
Bugs item #3047744, was opened at 2010-08-18 15:26 Message generated for change (Comment added) made by maharaja You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3047744&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Colin Viebrock (cviebrock) Assigned to: Nobody/Anonymous (nobody) Summary: Vacation removal doesn't clear out old notifications Initial Comment: When you turn off vacation, PFA doesn't remove the list of people who were notified. The next time you enable vacation, those people won't receive the new notifications. The solution (I think) is to clear the list of notifications each time vacation is enabled. Here's a patch to do that against SVN rev. 856. ---------------------------------------------------------------------- Comment By: maharaja (maharaja) Date: 2011-06-20 14:38 Message: other possible solutions include: 1. re-notify if notified_at < activefrom 2. use vacation.pl to delete all vacation_notified entries where notified_at < activefrom btw - this should happen even if interval = 0 ! ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-08-22 23:37 Message: I just had a quick look at the code - there's already a DELETE query in line 121 (2.3 branch) / line 126 (trunk) that should in theory do that. Your bugreport shows that practise seems to be different ;-) - we'll have to check that... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3047744&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-20 12:33:04
|
Bugs item #3086890, was opened at 2010-10-13 22:18 Message generated for change (Comment added) made by maharaja You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3086890&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johan Meiring (jmeiring) Assigned to: Nobody/Anonymous (nobody) Summary: vacation.pl does not log to mail facility when using syslog Initial Comment: vacation.pl does not seem to use the 'mail' facility when using syslog. It seems related to the word "Facility" starting with a capital F. The following patch fixes it: mailhost:/var/spool/vacation# diff -u vacation.pl.orig vacation.pl --- vacation.pl.orig 2010-10-13 22:12:03.000000000 +0200 +++ vacation.pl 2010-10-13 22:14:32.000000000 +0200 @@ -214,7 +214,7 @@ if($syslog == 1) { my $syslog_appender = Log::Log4perl::Appender->new( 'Log::Dispatch::Syslog', - Facility => 'mail', + facility => 'mail', ); $logger->add_appender($syslog_appender); } ---------------------------------------------------------------------- Comment By: maharaja (maharaja) Date: 2011-06-20 14:32 Message: i can confirm this on debian 6.0 using liblog-log4perl-perl 1.29-1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3086890&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-16 17:25:14
|
Bugs item #3305307, was opened at 2011-05-20 15:28 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305307&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Domain drop down broken as domain admin in 1059 Initial Comment: The domain drop down is empty and this shows up in syslog when logged in as a domain admin and "Domain list" is clicked. PHP Notice: Undefined index: domain in /srv/http/postfixadmin-svn-1059/list-domain.php on line 119 Let me know if I should stop reporting things in the SVN version. I saw a lot of bug reports fixed in SVN since 2.3.3 and no new releases so I'm trying to run SVN. ---------------------------------------------------------------------- >Comment By: Dale Blount (lnxus) Date: 2011-06-16 13:25 Message: <supa_user> as far as bug 3305307 goes - what is it supposed to do? <cboltz> the expected behaviour when logged in as superadmin is: <cboltz> display the list of admins, and then limit the domain list to domains that are available to this admin <cboltz> (something like "simulate login as ad...@cu...") <cboltz> when logged in as domain admin, that behaviour is pointless <cboltz> 2.3.x displays a list of domains in the dropdown, but does nothing when you select one <cboltz> I tend to hide the dropdown for domain admins <supa_user> what if they have several domains? <cboltz> that's better than different behaviour for superadmins and domain admins <supa_user> or is that not possible? <cboltz> the domains are still displayed in the page body <cboltz> even if the dropdown isn't there <supa_user> the dropdown could be limited to their domains though, right? <cboltz> login as superadmin and check what the dropdown does <cboltz> (hint: it contains a list of _admins_, not domains - and that is something that is not useful/allowed for domain admins) <cboltz> I'd say options are <cboltz> a) hide the dropdown for domain admins <cboltz> b) only list one admin username: the currently logged ---------------------------------------------------------------------- Comment By: Dale Blount (lnxus) Date: 2011-05-23 15:53 Message: Possibly related to this bug: the drop down on the "Domain List" page as superadmin lists admin login addresses and not domains. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-22 07:15 Message: Please continue to report bugs in the SVN version - for example, this bug is new to me because I usually test as superadmin ;-) (If you have some PHP knownledge: we also accept patches of course, but we are also happy to "just" get bugreports ;-) The reason for not doing a release is that SVN currently doesn't have the quality we want to have for a release. IMHO it's useable (well, as soon as someone fixes this bug) even in production, but there are still several small bugs left that prevent a release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305307&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-16 16:21:10
|
Bugs item #3066059, was opened at 2010-09-14 18:32 Message generated for change (Comment added) made by robelix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3066059&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v2.3.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: space in aliases shouldn't be allowed Initial Comment: Accidential ;-) finding by a customer: When creating an alias, you can enter " foo" in the from field. This results in the creation of an " fo...@ex..." alias (with leading space!) and people will wonder why the alias will fail with "user unknown". PostfixAdmin should prevent spaces - either with trim() or with a error message. ---------------------------------------------------------------------- Comment By: roland obermayer (robelix) Date: 2011-06-16 18:21 Message: Just had a pretty similar issue: A domain "example.com " - with a space at the end - was added. It seems that postfix does not mind - mails are. But in postfixadmin it's impossilbe to select it in the virtual-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3066059&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-13 13:55:38
|
Patches item #2974928, was opened at 2010-03-23 00:14 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: Domain Level Quotas Initial Comment: Enables domain-level quota management by modifing the check_quota function in functions.php to check against the current total quota for the domain. A third, optional argument $username has been added for the case of modifying a quota, the user's current quota is excluded from the total. Minor modification to edit-mailbox.php to pass the username in the third argument. Notes: - Currently provides no front-end modification to a domain-level quota information, domain quotas must be set in the database - Patch created based on v2.3 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-13 15:55 Message: Domain level quotas will be part of the next trunk-based release (probably 3.0), but I won't backport it to the 2.3 branch. You can try the patch that is attached to this bugreport - it was made for 2.3, therefore it most probably works with 2.3.3 also. Basically you can use SVN trunk on a production server - the web interface has some small (mostly optical) glitches, but in general it should be useable. The new features, especially the command line interface, are still incomplete, but the implemented parts should work. (BTW: If you have a package with lots of free time, send it to me ;-)) ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 15:35 Message: Reading through this again, now I understand the oldest comments are at the bottom, I see this has only been in trunk since after the 2.3 release, and also since after the last changes to branches/2.3/CHANGELOG.TXT , so I suppose it is fairly likely to get into the next release. ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 15:29 Message: Or does anyone know if this patch is likely to work with 2.3.3 ? ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 15:25 Message: Does anyone know if and when this patch is likely to make it into a release? I see that it is in trunk but not in the 2.3 branch, and there are one or two other similar patches for postfixadmin on other websites. Or if people are using a version of the trunk successfully for virtual hosting. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 22:39 Message: ... and finally *drum roll* commited the changes in core files and templates to SVN trunk r1042 - with some modifications, cleanup and adoptions to trunk. See the SVN commit message for details. Thanks for your patch! I also added support for domain-level quota to model/DomainHandler.php and the CLI in SVN r1043, r1044 and r1045. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 21:52 Message: step two: languages/* (for all languages) commited to SVN trunk r1041. Compared to your patch, I removed duplicate texts to avoid duplicate work for translators. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 21:10 Message: first step: CSS cleanup commited to SVN r1039 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 13:34 Message: FYI: I'm currently (finally!) working on including this patch in SVN trunk. I have some small modifications (for example I "recycle" some $LANG strings to avoid duplicate work for translators, and have to redo the template changes because trunk uses smarty templates in the meantime). I'll commit it in the next days. ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 19:57 Message: The add/edit domain pages were simpler and faster to modify than I thought. The unified patch below rolls in quota checking, display, and addition/editing as well as the relevant additions to $CONF and english language file. This patch also rolls in a resolution to the edit-alias.php bug: https://sourceforge.net/tracker/?func=detail&aid=2976010&group_id=191583&atid=937964 ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 19:02 Message: added a patch to display domain quotas in super-admin and domain-admin list-domain.php, line numbering in config.inc.php might be a bit squiffy. also, list-domain.php does the legwork for gathering domain information into the $domain_properties array, why does templates/overview_get.php do it over again with get_domain_properties()? ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-23 00:18 Message: * also assumes 'domain.quota' field is in MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-13 13:35:16
|
Patches item #2974928, was opened at 2010-03-22 23:14 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: Domain Level Quotas Initial Comment: Enables domain-level quota management by modifing the check_quota function in functions.php to check against the current total quota for the domain. A third, optional argument $username has been added for the case of modifying a quota, the user's current quota is excluded from the total. Minor modification to edit-mailbox.php to pass the username in the third argument. Notes: - Currently provides no front-end modification to a domain-level quota information, domain quotas must be set in the database - Patch created based on v2.3 ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:35 Message: Reading through this again, now I understand the oldest comments are at the bottom, I see this has only been in trunk since after the 2.3 release, and also since after the last changes to branches/2.3/CHANGELOG.TXT , so I suppose it is fairly likely to get into the next release. ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:29 Message: Or does anyone know if this patch is likely to work with 2.3.3 ? ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:25 Message: Does anyone know if and when this patch is likely to make it into a release? I see that it is in trunk but not in the 2.3 branch, and there are one or two other similar patches for postfixadmin on other websites. Or if people are using a version of the trunk successfully for virtual hosting. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 20:39 Message: ... and finally *drum roll* commited the changes in core files and templates to SVN trunk r1042 - with some modifications, cleanup and adoptions to trunk. See the SVN commit message for details. Thanks for your patch! I also added support for domain-level quota to model/DomainHandler.php and the CLI in SVN r1043, r1044 and r1045. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:52 Message: step two: languages/* (for all languages) commited to SVN trunk r1041. Compared to your patch, I removed duplicate texts to avoid duplicate work for translators. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:10 Message: first step: CSS cleanup commited to SVN r1039 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 11:34 Message: FYI: I'm currently (finally!) working on including this patch in SVN trunk. I have some small modifications (for example I "recycle" some $LANG strings to avoid duplicate work for translators, and have to redo the template changes because trunk uses smarty templates in the meantime). I'll commit it in the next days. ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:57 Message: The add/edit domain pages were simpler and faster to modify than I thought. The unified patch below rolls in quota checking, display, and addition/editing as well as the relevant additions to $CONF and english language file. This patch also rolls in a resolution to the edit-alias.php bug: https://sourceforge.net/tracker/?func=detail&aid=2976010&group_id=191583&atid=937964 ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:02 Message: added a patch to display domain quotas in super-admin and domain-admin list-domain.php, line numbering in config.inc.php might be a bit squiffy. also, list-domain.php does the legwork for gathering domain information into the $domain_properties array, why does templates/overview_get.php do it over again with get_domain_properties()? ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-22 23:18 Message: * also assumes 'domain.quota' field is in MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-13 13:29:36
|
Patches item #2974928, was opened at 2010-03-22 23:14 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: Domain Level Quotas Initial Comment: Enables domain-level quota management by modifing the check_quota function in functions.php to check against the current total quota for the domain. A third, optional argument $username has been added for the case of modifying a quota, the user's current quota is excluded from the total. Minor modification to edit-mailbox.php to pass the username in the third argument. Notes: - Currently provides no front-end modification to a domain-level quota information, domain quotas must be set in the database - Patch created based on v2.3 ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:29 Message: Or does anyone know if this patch is likely to work with 2.3.3 ? ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:25 Message: Does anyone know if and when this patch is likely to make it into a release? I see that it is in trunk but not in the 2.3 branch, and there are one or two other similar patches for postfixadmin on other websites. Or if people are using a version of the trunk successfully for virtual hosting. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 20:39 Message: ... and finally *drum roll* commited the changes in core files and templates to SVN trunk r1042 - with some modifications, cleanup and adoptions to trunk. See the SVN commit message for details. Thanks for your patch! I also added support for domain-level quota to model/DomainHandler.php and the CLI in SVN r1043, r1044 and r1045. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:52 Message: step two: languages/* (for all languages) commited to SVN trunk r1041. Compared to your patch, I removed duplicate texts to avoid duplicate work for translators. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:10 Message: first step: CSS cleanup commited to SVN r1039 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 11:34 Message: FYI: I'm currently (finally!) working on including this patch in SVN trunk. I have some small modifications (for example I "recycle" some $LANG strings to avoid duplicate work for translators, and have to redo the template changes because trunk uses smarty templates in the meantime). I'll commit it in the next days. ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:57 Message: The add/edit domain pages were simpler and faster to modify than I thought. The unified patch below rolls in quota checking, display, and addition/editing as well as the relevant additions to $CONF and english language file. This patch also rolls in a resolution to the edit-alias.php bug: https://sourceforge.net/tracker/?func=detail&aid=2976010&group_id=191583&atid=937964 ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:02 Message: added a patch to display domain quotas in super-admin and domain-admin list-domain.php, line numbering in config.inc.php might be a bit squiffy. also, list-domain.php does the legwork for gathering domain information into the $domain_properties array, why does templates/overview_get.php do it over again with get_domain_properties()? ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-22 23:18 Message: * also assumes 'domain.quota' field is in MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-13 13:25:50
|
Patches item #2974928, was opened at 2010-03-22 23:14 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: Domain Level Quotas Initial Comment: Enables domain-level quota management by modifing the check_quota function in functions.php to check against the current total quota for the domain. A third, optional argument $username has been added for the case of modifying a quota, the user's current quota is excluded from the total. Minor modification to edit-mailbox.php to pass the username in the third argument. Notes: - Currently provides no front-end modification to a domain-level quota information, domain quotas must be set in the database - Patch created based on v2.3 ---------------------------------------------------------------------- Comment By: Barney Laurance () Date: 2011-06-13 13:25 Message: Does anyone know if and when this patch is likely to make it into a release? I see that it is in trunk but not in the 2.3 branch, and there are one or two other similar patches for postfixadmin on other websites. Or if people are using a version of the trunk successfully for virtual hosting. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 20:39 Message: ... and finally *drum roll* commited the changes in core files and templates to SVN trunk r1042 - with some modifications, cleanup and adoptions to trunk. See the SVN commit message for details. Thanks for your patch! I also added support for domain-level quota to model/DomainHandler.php and the CLI in SVN r1043, r1044 and r1045. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:52 Message: step two: languages/* (for all languages) commited to SVN trunk r1041. Compared to your patch, I removed duplicate texts to avoid duplicate work for translators. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 19:10 Message: first step: CSS cleanup commited to SVN r1039 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-19 11:34 Message: FYI: I'm currently (finally!) working on including this patch in SVN trunk. I have some small modifications (for example I "recycle" some $LANG strings to avoid duplicate work for translators, and have to redo the template changes because trunk uses smarty templates in the meantime). I'll commit it in the next days. ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:57 Message: The add/edit domain pages were simpler and faster to modify than I thought. The unified patch below rolls in quota checking, display, and addition/editing as well as the relevant additions to $CONF and english language file. This patch also rolls in a resolution to the edit-alias.php bug: https://sourceforge.net/tracker/?func=detail&aid=2976010&group_id=191583&atid=937964 ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-25 18:02 Message: added a patch to display domain quotas in super-admin and domain-admin list-domain.php, line numbering in config.inc.php might be a bit squiffy. also, list-domain.php does the legwork for gathering domain information into the $domain_properties array, why does templates/overview_get.php do it over again with get_domain_properties()? ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-03-22 23:18 Message: * also assumes 'domain.quota' field is in MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2974928&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-02 22:58:48
|
Feature Requests item #1951926, was opened at 2008-04-25 23:38 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1951926&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: show_custom_colors - several enhancements Initial Comment: (SVN r343) (Combined to a single item because it affects one code section. Can be splitted as needed later.) While upgrading a production server to the latest SVN version (aka 2.2rc5), I found some things that show_custom_colors could do better: (1) $CONF['show_undeliverable'] shows a) aliases with non-existing local target b) aliases pointing to an external address which may cause some confusion. This should be splitted to $CONF['show_undeliverable'] for a) $CONF['show_external_alias'] for b) (We could also change "possible undeliverable" to "undeliverable".) (2) $CONF['vacation_domain'] should be in $CONF['show_undeliverable_exceptions'] by default (3) $CONF['show_status_key']='YES' shows all possible markers. I'd like to have the option to only show the _used_ markers to avoid displaying too many items (4) $CONF['vacation_domain'] should be part of $CONF['show_custom_domains']. It would be even better if it had an own setting (like $CONF['show_vacation_status']) which would allow a better description text than "delivery to autoreply.domain" (5) It should be possible to specify custom legend texts per domain in $CONF['show_custom_domains']. This could cover the special vacation marker I described above, as well as other cases. The custom legend texts should support two methods: a) static text, could also come from lang/* $text = "foobar"; b) array with translations, with fallback to "default" $text = array( 'default' => 'english text', 'de' => 'german text'); (6) $CONF['show_custom_count'] can be dropped - just use count($CONF['show_custom_domains']) instead. (7) A marker for mailboxes with non-default alias would also be helpful. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-03 00:58 Message: (2) fixed in SVN trunk r1068. Interestingly, it was "only" a bug. In theory this should already have worked already, but $stat_vacdomain missed the first letter of the domain ("xample.com" instead of "example.com") which broke it. Note to myself for backporting to 2.3.x (not sure if I'll do it since it will change behaviour): using $stat_domain instead of $stat_vacdomain will work - both variables have the same content anyway (at least in the bug-free version ;-) Remaining parts: (1) (3) (4) (5) and (7) ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-05-03 19:26 Message: (8) is done in SVN r650 - config variable: $CONF['recipient_delimiter'] Remaining parts: (1) (2) (3) (4) (5) and (7) ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-11-01 21:19 Message: (6) is done in SVN r471 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-04-26 01:39 Message: Logged In: YES user_id=593261 Originator: YES (8) Postfix supports a recipient_delimiter (usually "+") which allows to specify some type of parameter to a mail adress. An example would be fo...@ex..., which delivers to the fo...@ex... mailbox. Currently a mail with fo...@ex... is tagged as undeliverable even if the fo...@ex... mailbox exists. Proposal: $CONF['recipient_delimiter'] = "+"; (or "" to disable) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1951926&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-02 19:09:32
|
Bugs item #3306933, was opened at 2011-05-24 15:38 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-02 21:09 Message: That's really interesting. The empty value instead of 0 sounds like a funny[tm] PHP automatic type conversation to me (string instead of int). Since you seem to be the only one who has/had this problem, I'll close the bug as fixed. Feel free to reopen if you still have problems with r1064 or newer (or in the 2.3.3 release). ---------------------------------------------------------------------- Comment By: Keith Dunnett (magick777) Date: 2011-06-01 02:15 Message: More and more bizarre; maxquota works fine unquoted, leading me to suspect that the problem lies in whatever PHP is feeding to SQL for quota. One debug statement later: UPDATE domain SET description='Redirect',aliases=0,mailboxes=-1,maxquota=-1,quota=,transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardremit.com' so, the problem has precious little to do with quoting, it has to do with there being no quota passed to the query. In my DB, the quota field is "0" for all domains, so for reasons I haven't yet looked into, the edit-domain code in 1061 seems to be losing that value as I edit a domain. My apologies for a less than complete bug report; since quoting fixed the problem, I assumed it was the problem. Oops. However, I agree this isn't worth chasing further (for me at least), and less so still if quota and domainquota are working in current SVN. I suspect it might come down to "user has upgraded and not configured something right", or to a bug that no longer exists. Either way, thanks for looking at it and I'll try 1064. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 01:27 Message: A possible explanation: the quota and maxquota fields are of type "bigint", the aliases and mailboxes fields are "int". Can you test if you need the quotes for unlimited maxquota also? Regarding debugging: You can use something like "echo $query;" to print the query - and then copy it into a MySQL shell and shorten it (delete one field after the other, then re-add them one by one in another order) to find out which part breaks. If you are unsure which changes you did to the file, run "svn diff" to see the changes or "svn revert" to go back to the file as it exists in SVN (this will overwrite all your changes!). The fix I did in SVN trunk is too intrusive for a backport to the 2.3 branch IMHO, therefore I'd have to "just" add quotes in the 2.3 branch. And for that it would be good to know which fields are affected by this bug and how your working query/code looks like. OTOH, you are the first one who hit this bug - therefore we shouldn't invest too much time for the backport ;-) ---------------------------------------------------------------------- Comment By: Keith Dunnett (magick777) Date: 2011-06-01 00:21 Message: Database is MySQL 5.1.49-3, shipped with Debian 6. Problem does not occur with other fields (mailboxes and aliases); these seem to accept a value of -1 without having quoted them in the SQL query. Doesn't make much sense. Removed the single quotes again to check I'm not going mad. Having done so, editing any domain now fails regardless of the quota value, with: DEBUG INFORMATION: Invalid query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardre' at line 1 This applies regardless of the quota value specified, it turns out, which confuses me more. But, I put the quotes back in and the query succeeds with the quota correctly recorded - whether or not that quota is a positive or negative integer. Colour me (very) confused; my description of the issue now seems imperfect, but, it breaks as soon as I remove the quotes. I'll hold off for a couple more days on 1064 in case there's any more debugging I can usefully do, but, if the problem is fixed in latest SVN it may or may not be worth spending too much debug time on it. Let me know if I can usefully test anything else against 1061. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-31 23:51 Message: Hmm, what database are you using? I can't reproduce it with MySQL. Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases? Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch. Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-01 17:37:24
|
Bugs item #2958684, was opened at 2010-02-25 07:49 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2958684&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: $CONF['admin_email'] ignored in most cases Initial Comment: [13:42] <mrfrenzy> in the configfile it says // This will be used to send emails from to create mailboxes. [13:42] <mrfrenzy> $CONF['admin_email'] [13:42] <mrfrenzy> however, when I create mailboxes the welcome mail is sent with my username as sender [13:44] <cboltz> indeed. a quick grep shows that it is only used by broadcast-message.php [13:44] <cboltz> the question is which behaviour is better [13:44] <cboltz> a) always use the admin_email sender [13:44] <cboltz> b) drop admin_email and use the admin username [13:44] <cboltz> what would you prefer? ;-) [13:45] <mrfrenzy> it really isn't that important, aslong as the instructions in the config filer are correct [13:46] <mrfrenzy> however. I do think there might be reasons you don't want to tell the users what username your adminuser has [13:46] <cboltz> good argument ;-) [13:47] <cboltz> I'll paste the above lines in the bugtracker... [13:47] <mrfrenzy> I really love this irc based bugtracker submission engine :P ---------------------------------------------------------------------- Comment By: Dale Blount (lnxus) Date: 2011-06-01 13:37 Message: I feel that super admin's loginname/email address should not be sent via email at all. Is it feasable to use $CONF['admin_email'] if logged in as a superadmin or use the domain admin's email if logged in as a domain admin? If not, $CONF['admin_email'] all the time for all purposes is fine by me. ---------------------------------------------------------------------- Comment By: Tabmow (tabmowtez) Date: 2010-03-02 17:06 Message: Well, it is a solution. I guess it depends on what sort of hosting situation we are trying to cater for. If people use postfixadmin to setup client domains, then it is feasible that people that create mailboxes in domain b don't want the welcome message to come from ad...@do.... One way is to have an extra field in the domain table called admin_email possibly? Obviously the $fFrom in create-mailbox.php would change but I see this as a full solution to cater for everyone. If that field is blank then it can resort back to $CONF['admin_email']. Alternatively you can make it a required field moving forward? Thoughts? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-03-02 10:09 Message: Idea: $CONF['admin_email'] = '' -> use the mail address of the logged in admin $CONF['admin_email'] = "fo...@ex..." -> always use fo...@ex... What do you think about this solution? ---------------------------------------------------------------------- Comment By: Tabmow (tabmowtez) Date: 2010-03-01 23:52 Message: Quick change in create-mailbox.php should fix this. --- create-mailbox.php 2009-04-07 05:54:11.000000000 +1000 +++ /usr/local/www/postfixadmin/create-mailbox.php 2010-03-02 15:48:26.000000000 +1100 @@ -230,7 +230,7 @@ if ($fMail == "on") { $fTo = $fUsername; - $fFrom = $SESSID_USERNAME; + $fFrom = $CONF['admin_email']; $fHeaders = "To: " . $fTo . "\n"; $fHeaders .= "From: " . $fFrom . "\n"; Might be possible to add another config option and being able to define an address as well? Possible a per domain address? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2958684&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-06-01 00:15:59
|
Bugs item #3306933, was opened at 2011-05-24 14:38 Message generated for change (Comment added) made by magick777 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- Comment By: Keith Dunnett (magick777) Date: 2011-06-01 01:15 Message: More and more bizarre; maxquota works fine unquoted, leading me to suspect that the problem lies in whatever PHP is feeding to SQL for quota. One debug statement later: UPDATE domain SET description='Redirect',aliases=0,mailboxes=-1,maxquota=-1,quota=,transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardremit.com' so, the problem has precious little to do with quoting, it has to do with there being no quota passed to the query. In my DB, the quota field is "0" for all domains, so for reasons I haven't yet looked into, the edit-domain code in 1061 seems to be losing that value as I edit a domain. My apologies for a less than complete bug report; since quoting fixed the problem, I assumed it was the problem. Oops. However, I agree this isn't worth chasing further (for me at least), and less so still if quota and domainquota are working in current SVN. I suspect it might come down to "user has upgraded and not configured something right", or to a bug that no longer exists. Either way, thanks for looking at it and I'll try 1064. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 00:27 Message: A possible explanation: the quota and maxquota fields are of type "bigint", the aliases and mailboxes fields are "int". Can you test if you need the quotes for unlimited maxquota also? Regarding debugging: You can use something like "echo $query;" to print the query - and then copy it into a MySQL shell and shorten it (delete one field after the other, then re-add them one by one in another order) to find out which part breaks. If you are unsure which changes you did to the file, run "svn diff" to see the changes or "svn revert" to go back to the file as it exists in SVN (this will overwrite all your changes!). The fix I did in SVN trunk is too intrusive for a backport to the 2.3 branch IMHO, therefore I'd have to "just" add quotes in the 2.3 branch. And for that it would be good to know which fields are affected by this bug and how your working query/code looks like. OTOH, you are the first one who hit this bug - therefore we shouldn't invest too much time for the backport ;-) ---------------------------------------------------------------------- Comment By: Keith Dunnett (magick777) Date: 2011-05-31 23:21 Message: Database is MySQL 5.1.49-3, shipped with Debian 6. Problem does not occur with other fields (mailboxes and aliases); these seem to accept a value of -1 without having quoted them in the SQL query. Doesn't make much sense. Removed the single quotes again to check I'm not going mad. Having done so, editing any domain now fails regardless of the quota value, with: DEBUG INFORMATION: Invalid query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardre' at line 1 This applies regardless of the quota value specified, it turns out, which confuses me more. But, I put the quotes back in and the query succeeds with the quota correctly recorded - whether or not that quota is a positive or negative integer. Colour me (very) confused; my description of the issue now seems imperfect, but, it breaks as soon as I remove the quotes. I'll hold off for a couple more days on 1064 in case there's any more debugging I can usefully do, but, if the problem is fixed in latest SVN it may or may not be worth spending too much debug time on it. Let me know if I can usefully test anything else against 1061. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-31 22:51 Message: Hmm, what database are you using? I can't reproduce it with MySQL. Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases? Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch. Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-31 23:39:36
|
Bugs item #3306452, was opened at 2011-05-23 21:35 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306452&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Comment wording vs behavior is confusing Initial Comment: config.inc.php says this: // Site Admin // Define the Site Admins email address below. // This will be used to send emails from to create mailboxes. $CONF['admin_email'] = 'pos...@ch...d'; Yet emails appear to come from my superadmin address instead. I see in model/MailboxHandler.php that $fFrom = Config::read('admin_email'); but it doesn't seem to be working for some reason. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 01:39 Message: You are right, $CONF['admin_email'] should be used in more places (or we should drop the config option and always use the (super)admin username). This is a known issue, see https://sourceforge.net/tracker/?func=detail&aid=2958684&group_id=191583&atid=937964 for details and possible solutions. Feel free to add your opinion there ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306452&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-31 23:27:25
|
Bugs item #3306933, was opened at 2011-05-24 15:38 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 01:27 Message: A possible explanation: the quota and maxquota fields are of type "bigint", the aliases and mailboxes fields are "int". Can you test if you need the quotes for unlimited maxquota also? Regarding debugging: You can use something like "echo $query;" to print the query - and then copy it into a MySQL shell and shorten it (delete one field after the other, then re-add them one by one in another order) to find out which part breaks. If you are unsure which changes you did to the file, run "svn diff" to see the changes or "svn revert" to go back to the file as it exists in SVN (this will overwrite all your changes!). The fix I did in SVN trunk is too intrusive for a backport to the 2.3 branch IMHO, therefore I'd have to "just" add quotes in the 2.3 branch. And for that it would be good to know which fields are affected by this bug and how your working query/code looks like. OTOH, you are the first one who hit this bug - therefore we shouldn't invest too much time for the backport ;-) ---------------------------------------------------------------------- Comment By: Keith Dunnett (magick777) Date: 2011-06-01 00:21 Message: Database is MySQL 5.1.49-3, shipped with Debian 6. Problem does not occur with other fields (mailboxes and aliases); these seem to accept a value of -1 without having quoted them in the SQL query. Doesn't make much sense. Removed the single quotes again to check I'm not going mad. Having done so, editing any domain now fails regardless of the quota value, with: DEBUG INFORMATION: Invalid query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardre' at line 1 This applies regardless of the quota value specified, it turns out, which confuses me more. But, I put the quotes back in and the query succeeds with the quota correctly recorded - whether or not that quota is a positive or negative integer. Colour me (very) confused; my description of the issue now seems imperfect, but, it breaks as soon as I remove the quotes. I'll hold off for a couple more days on 1064 in case there's any more debugging I can usefully do, but, if the problem is fixed in latest SVN it may or may not be worth spending too much debug time on it. Let me know if I can usefully test anything else against 1061. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-31 23:51 Message: Hmm, what database are you using? I can't reproduce it with MySQL. Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases? Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch. Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-31 23:07:51
|
Bugs item #3306926, was opened at 2011-05-24 15:34 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: check_quota function fails to handle unlimited quota Initial Comment: (found in SVN 1061) When a domain's quota is set to "0", meaning "unlimited quota" according to the web interface, all edits to a user's quota are rejected as too high. The problem is in the function "check_quota", which checks if ($quota > $limit['maxquota']) { $rval = false; } AFTER it checks if ($limit['maxquota'] == 0) { $rval = true; } and therefore declines any quota for being greater than the "maximum" of 0. Reversing these two checks fixes the problem and causes a quota of 0 to return a successful quota_check as expected. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-06-01 01:07 Message: I prefer code that does not depend on the execution order too much ;-) check_quota() was more or less rewritten to support domain-level total quota. On the positive side this means that 2.3.x is not affected by this bug. I just changed some parts of the function back to the 2.3.x state - it now uses "return true/false" again instead of settiong $rval if the result is final (as in "can't be changed by domain quota check"). I also added several comments that explain what the function is doing after it took me a while to understand it ;-) The bug you reported is fixed by this change: - if ($quota > $limit['maxquota']) { + if ($limit['maxquota'] != 0 && $quota > $limit['maxquota']) { This excludes the "unlimited" maxquota from the check and should therefore solve the problem. Commited to SVN trunk r1065. Thanks for the bugreport! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-31 22:21:36
|
Bugs item #3306933, was opened at 2011-05-24 14:38 Message generated for change (Comment added) made by magick777 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- >Comment By: Keith Dunnett (magick777) Date: 2011-05-31 23:21 Message: Database is MySQL 5.1.49-3, shipped with Debian 6. Problem does not occur with other fields (mailboxes and aliases); these seem to accept a value of -1 without having quoted them in the SQL query. Doesn't make much sense. Removed the single quotes again to check I'm not going mad. Having done so, editing any domain now fails regardless of the quota value, with: DEBUG INFORMATION: Invalid query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'transport='virtual', backupmx='0',active='1',modified=NOW() WHERE domain='cardre' at line 1 This applies regardless of the quota value specified, it turns out, which confuses me more. But, I put the quotes back in and the query succeeds with the quota correctly recorded - whether or not that quota is a positive or negative integer. Colour me (very) confused; my description of the issue now seems imperfect, but, it breaks as soon as I remove the quotes. I'll hold off for a couple more days on 1064 in case there's any more debugging I can usefully do, but, if the problem is fixed in latest SVN it may or may not be worth spending too much debug time on it. Let me know if I can usefully test anything else against 1061. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-31 22:51 Message: Hmm, what database are you using? I can't reproduce it with MySQL. Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases? Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch. Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-31 21:51:34
|
Bugs item #3306933, was opened at 2011-05-24 15:38 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-05-31 23:51 Message: Hmm, what database are you using? I can't reproduce it with MySQL. Another question: does this bug also happen with the other fields, for example the numer of mailboxes and aliases? Please check this - it would be good to know if I decide to backport the fix to the 2.3 branch. Afterwards, please update to the latest SVN version. I replaced the query to use db_update() in SVN r1064 which results in more readable code and, as a side effect ;-) also fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-24 13:38:31
|
Bugs item #3306933, was opened at 2011-05-24 14:38 Message generated for change (Tracker Item Submitted) made by magick777 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: edit-domain.php fails to handle disabled quota Initial Comment: (found in SVN 1061) SQL query at line 110 of edit-domain.php fails with an error in SQL syntax. quota=$fDomainquota needs to be in single quotes, i.e. quota='$fDomainquota', in order to accept a value of '-1'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306933&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-24 13:34:15
|
Bugs item #3306926, was opened at 2011-05-24 14:34 Message generated for change (Tracker Item Submitted) made by magick777 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Dunnett (magick777) Assigned to: Nobody/Anonymous (nobody) Summary: check_quota function fails to handle unlimited quota Initial Comment: (found in SVN 1061) When a domain's quota is set to "0", meaning "unlimited quota" according to the web interface, all edits to a user's quota are rejected as too high. The problem is in the function "check_quota", which checks if ($quota > $limit['maxquota']) { $rval = false; } AFTER it checks if ($limit['maxquota'] == 0) { $rval = true; } and therefore declines any quota for being greater than the "maximum" of 0. Reversing these two checks fixes the problem and causes a quota of 0 to return a successful quota_check as expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306926&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-23 20:34:29
|
Bugs item #3306203, was opened at 2011-05-23 11:16 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306203&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: SVN (please specify revision!) >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: john doe (johndoe64) Assigned to: Nobody/Anonymous (nobody) Summary: Cant login - can't encrypt password with dovecotpw Initial Comment: After updating dovecot to version 2.0.13 postfixadmin cant login. On website it shows the message "can't encrypt password with dovecotpw" and in apache-log file it writes: "doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 85: Couldn't open include file /etc/dovecot/conf.d/90-sieve.conf: Permission denied" All config files from dovecot are having the same permissions. --- > ls -R /etc/dovecot/ /etc/dovecot/: total 80K drwxr-xr-x 3 root root 4.0K May 18 14:32 . drwxr-xr-x 90 root root 4.0K May 18 21:03 .. -rw-r--r-- 1 root root 116 Mar 12 21:41 README drw-r--r-- 2 root root 4.0K May 18 14:37 conf.d -rw-r--r-- 1 root root 410 Jan 25 00:28 dovecot-db-example.conf -rw-r--r-- 1 root root 410 Mar 12 21:41 dovecot-db.conf.ext -rw-r--r-- 1 root root 782 Jan 25 00:28 dovecot-dict-sql-example.conf -rw-r--r-- 1 root root 374 Mar 19 10:11 dovecot-dict-sql.conf.ext -rw-r--r-- 1 root root 4.9K Jan 25 00:29 dovecot-ldap.conf -rw-r--r-- 1 root root 5.1K Mar 12 21:41 dovecot-ldap.conf.ext -rw-r--r-- 1 root root 5.3K Mar 12 21:41 dovecot-sql.conf -rw-r--r-- 1 root root 5.5K Mar 19 15:16 dovecot-sql.conf.ext -rw-r--r-- 1 root root 5.3K May 16 22:51 dovecot-sql.conf.ext.ucf-dist -rw-r--r-- 1 root root 3.7K Mar 15 19:02 dovecot.conf -rw-r--r-- 1 root root 3.7K May 16 22:51 dovecot.conf.ucf-dist /etc/dovecot/conf.d: total 136K drw-r--r-- 2 root root 4.0K May 18 14:37 . drwxr-xr-x 3 root root 4.0K May 18 14:32 .. -rw-r--r-- 1 root root 5.2K Mar 29 17:53 10-auth.conf -rw-r--r-- 1 root root 5.2K May 16 22:51 10-auth.conf.ucf-dist -rw-r--r-- 1 root root 1.7K Mar 12 21:41 10-director.conf -rw-r--r-- 1 root root 2.8K Mar 29 13:20 10-logging.conf -rw-r--r-- 1 root root 2.6K May 16 22:51 10-logging.conf.ucf-dist -rw-r--r-- 1 root root 15K Mar 29 15:50 10-mail.conf -rw-r--r-- 1 root root 3.1K Mar 19 10:45 10-master.conf -rw-r--r-- 1 root root 1.7K Mar 29 15:37 10-ssl.conf -rw-r--r-- 1 root root 1.6K Mar 15 17:36 15-lda.conf -rw-r--r-- 1 root root 2.4K Mar 19 15:20 20-imap.conf -rw-r--r-- 1 root root 2.4K May 16 22:51 20-imap.conf.ucf-dist -rw-r--r-- 1 root root 468 Mar 29 16:26 20-lmtp.conf -rw-r--r-- 1 root root 469 May 16 22:51 20-lmtp.conf.ucf-dist -rw-r--r-- 1 root root 2.4K May 18 14:34 20-managesieve.conf -rw-r--r-- 1 root root 2.3K May 16 22:51 20-managesieve.conf.ucf-dist -rw-r--r-- 1 root root 3.5K Mar 12 21:41 20-pop3.conf -rw-r--r-- 1 root root 676 Mar 12 21:41 90-acl.conf -rw-r--r-- 1 root root 485 Mar 26 18:17 90-plugin.conf -rw-r--r-- 1 root root 2.3K Mar 19 15:39 90-quota.conf -rw-r--r-- 1 root root 2.5K Mar 12 21:41 90-sieve.conf -rw-r--r-- 1 root root 486 Mar 12 21:41 auth-deny.conf.ext -rw-r--r-- 1 root root 558 Mar 12 21:41 auth-master.conf.ext -rw-r--r-- 1 root root 329 Mar 12 21:41 auth-passwdfile.conf.ext -rw-r--r-- 1 root root 785 Mar 12 21:41 auth-sql.conf.ext -rw-r--r-- 1 root root 608 Mar 12 21:41 auth-static.conf.ext -rw-r--r-- 1 root root 2.1K Mar 12 21:41 auth-system.conf.ext -rw-r--r-- 1 root root 327 May 16 22:51 auth-vpopmail.conf.ext --- But if I delete 90_sieve.conf the next file will be shown - so it seams a generally problem. Dovecot by itself works like a charm and postfix also works. And a "doveadm pw -u USERNAME -p PASSWORD" will also print the hashed sequence. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-05-23 22:34 Message: > But fyi: the dovecot package will set it to 644 by the next upgrade. That's a bug in the dovecot package - please report it to your distribution/the packager. I'm closing this bug as "invalid", however the correct status would be "notmybug" ;-) ---------------------------------------------------------------------- Comment By: john doe (johndoe64) Date: 2011-05-23 12:50 Message: Thanks, now it works. But fyi: the dovecot package will set it to 644 by the next upgrade. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2011-05-23 12:40 Message: chmod 755 /etc/dovecot/conf.d (directory needs +x permission for it to be accessible) ---------------------------------------------------------------------- Comment By: john doe (johndoe64) Date: 2011-05-23 12:38 Message: > You'll probably have to set > $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; Well, this line Ive already changed and with dovecot version 2.0.11 it has work. The problems appear with newer dovecot version. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-23 12:29 Message: You'll probably have to set $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; (Besides that, this bug is probably a duplicate - but I don't have the time to check it at the moment.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306203&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-23 19:53:52
|
Bugs item #3305307, was opened at 2011-05-20 15:28 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305307&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Domain drop down broken as domain admin in 1059 Initial Comment: The domain drop down is empty and this shows up in syslog when logged in as a domain admin and "Domain list" is clicked. PHP Notice: Undefined index: domain in /srv/http/postfixadmin-svn-1059/list-domain.php on line 119 Let me know if I should stop reporting things in the SVN version. I saw a lot of bug reports fixed in SVN since 2.3.3 and no new releases so I'm trying to run SVN. ---------------------------------------------------------------------- >Comment By: Dale Blount (lnxus) Date: 2011-05-23 15:53 Message: Possibly related to this bug: the drop down on the "Domain List" page as superadmin lists admin login addresses and not domains. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-22 07:15 Message: Please continue to report bugs in the SVN version - for example, this bug is new to me because I usually test as superadmin ;-) (If you have some PHP knownledge: we also accept patches of course, but we are also happy to "just" get bugreports ;-) The reason for not doing a release is that SVN currently doesn't have the quality we want to have for a release. IMHO it's useable (well, as soon as someone fixes this bug) even in production, but there are still several small bugs left that prevent a release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305307&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-23 19:35:49
|
Bugs item #3306452, was opened at 2011-05-23 15:35 Message generated for change (Tracker Item Submitted) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306452&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Comment wording vs behavior is confusing Initial Comment: config.inc.php says this: // Site Admin // Define the Site Admins email address below. // This will be used to send emails from to create mailboxes. $CONF['admin_email'] = 'pos...@ch...d'; Yet emails appear to come from my superadmin address instead. I see in model/MailboxHandler.php that $fFrom = Config::read('admin_email'); but it doesn't seem to be working for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3306452&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-23 19:23:08
|
Bugs item #3305278, was opened at 2011-05-20 14:25 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305278&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot redeclare maildir_name_hook() Initial Comment: When upgrading 2.3.3 to svn via setup.php: Cannot redeclare maildir_name_hook() (previously declared in /srv/http/postfixadmin-svn-1059/config.inc.php:157) in /srv/http/postfixadmin-svn-1059/config.inc.php on line 163 Commenting out the function and $CONF['maildir_name_hook'] lets it get through setup.php and then adding mailboxes appears to work just fine. ---------------------------------------------------------------------- >Comment By: Dale Blount (lnxus) Date: 2011-05-23 15:23 Message: As hard as I try, I cannot reproduce this any longer... I think it was a bad config diff or something. I've since moved my local settings to config.local.php. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-22 07:31 Message: Hmm, it looks like your config.inc.php is somehow broken - I'd guess the example function lost the comment markers (/* ... */), and you have defined a custom hook function. Can you please run "svn diff" on config.inc.php and check if I'm right? (If unsure, post the diff - without database password of course ;-) BTW: You probably want to write your settings to config.local.php - that makes updates easier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3305278&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-05-23 14:06:13
|
Patches item #3305187, was opened at 2011-05-20 11:09 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3305187&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: Logging patch Initial Comment: Patch to add ability to only allow super admin to view logs ---------------------------------------------------------------------- >Comment By: Dale Blount (lnxus) Date: 2011-05-23 10:06 Message: Hi. Sorry about the old patch, this was before I started using the SVN version. The reason I want to have the option to hide the logs is that it logs IPs of the superadmins giving possible targets to gain additional privileges. Yes, I know it's quite a long shot. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-05-22 18:07 Message: Your patch hides the link to viewlog.php, but any domain admin can still type viewlog.php in his browser's address bar and view the log. You should add a permission check in viewlog.php to fix this. Additionally, our current development version is much different from 2.3.x because we switched to smarty templates. This means the template changes in your patch won't apply to SVN trunk. (Not a real problem, it would be quite easy for me to convert your patch to the smarty templates.) That said: is there a special reason why you want to hide the log from your domain admins? I have to admit that I don't see why this would make sense. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3305187&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
