postfixadmin-tracker Mailing List for PostfixAdmin (Page 23)
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...> - 2010-05-18 22:24:21
|
Bugs item #2967410, was opened at 2010-03-10 15:43 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2967410&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: v 2.3 Status: Open >Resolution: None Priority: 9 Private: No Submitted By: Milorad Vasilev (lory) Assigned to: Nobody/Anonymous (nobody) >Summary: virtual list terribly slow with lots of mailboxes/aliases Initial Comment: I have 100068 mailboxes in mailbox table. when select this domain I see mysql select like this | 19443 | postfix | localhost:52787 | postfix | Query | 1 | Sorting result | SELECT mailbox.username FROM mailbox WHERE mailbox.domain='cablemail.bg' ORDER BY mailbox.username LIMIT 3180, 1 | after a while | 19443 | postfix | localhost:52787 | postfix | Query | 1 | Sorting result | SELECT mailbox.username FROM mailbox WHERE mailbox.domain='cablemail.bg' ORDER BY mailbox.username LIMIT 3190, 1 | and so like 100000, it is a long time. Domain with 250 mailboxes work fine. I think that is a problem with paging accounts and aliases. Regards: M.Vasilev ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-19 00:24 Message: The problem (in get_domain_properties(), functions.inc.php) is that there's a loop querying every $entries_per_page'th entry (and its previous entry) to build the nice "aa-ax, ay-cu" page browser. Doing lots of (even small) queries is a guarantee for slowness. I guess it would be even faster to fetch all mailboxes into an array (one SELECT with a biiiig result) and loop over it on the PHP side - but that's not a good solution either. The number of queries can be cut down by 50% by using "LIMIT ($start_entry -1), 2" (read end of previous section and beginning of the new section in one SELECT - except for the very first "aa" query) without any function loss. Displaying more entries per page also reduces the number of queries, but I believe you that it still isn't fun with 100000 mailboxes ;-) (BTW: What's your $CONF('page_size') setting? How long does it take to load the page with the "nice", but slow pagebrowser?) ---------------------------------------------------------------------- Comment By: Milorad Vasilev (lory) Date: 2010-03-11 09:11 Message: Now I edit functions.inc.php and made thi changes 1. // if ( $list['alias_count'] > $page_size ) if ( 0 ) 2. // if ( $list['mailbox_count'] > $page_size ) if ( 0 ) Now I havn't mailbox index like this: :: Mailboxes aa-am am-bi bk-bt ce-dd di-dp ds-er es-gk gm-im im-it it-kd kd-ks kv-ma ma-mg mh-na na-no nt-pp pr-rm rr-rt rz-sk sk-ss sv-tl tm-vg vh-vl vm-vv vv-zo zs-zt But I can managed mailboxes and aliases. Lory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2967410&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 21:57:00
|
Bugs item #2909334, was opened at 2009-12-05 17:06 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2909334&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: v 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: ololo (fly-away) Assigned to: Nobody/Anonymous (nobody) Summary: seems to be alias_control in postfixadmin 2.3 broken Initial Comment: postfixadmin 2.3, php-5.3.1, mysql 5.0.77 Now I set all 3 params to YES: $CONF['alias_control'] = 'YES'; $CONF['alias_control_admin'] = 'YES'; $CONF['special_alias_control'] = 'YES'; and still cant see forward in 'Virtual list' BTW, I can see it in search output. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 23:57 Message: I backported this to the 2.3 branch yesterday - the mailbox list now has an additional column showing the alias target. (Regarding search.php vs. list-virtual.php - there's another bugreport still open for this ;-) ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-02-14 01:27 Message: I assume you are talking about the aliases of mailboxes. This is fixed in trunk (r751 and r787) and will be backported to the 2.3 branch (which will be released as 2.3.1). The mailbox list will have an additional column with the alias target. I'll keep this bug open until I merged the change into the 2.3 branch. Search output is another story - historically search is handled by a seperate script (search.php), but it will be merged into list-virtual.php. The code for this is mostly in place since r751. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2909334&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 21:26:17
|
Bugs item #2782818, was opened at 2009-04-28 14:55 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2782818&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: 4 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: search doesn't filter out mailbox aliases Initial Comment: Search results contain the mailbox aliases in the "Aliases" section. They should be filtered out and only be listed in the "Mailboxes" section. Better solution - merge search and list-virtual. Wichout having looked at it, the differences are probably only: - a different WHERE clause ;-) (searching for the entered text, not for a domain) - highlighting of search matches - (maybe: hide the "create alias"/"create mailbox" links) Everything else should work with the same code. Using the code from list-virtual is probably the better idea because it is used/tested more often. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 23:26 Message: That's implemented on the list-virtual.php side in the meantime. The remaining parts are: - change all scripts to call list-virtual.php instead of search.php - testing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2782818&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 21:15:03
|
Bugs item #2927127, was opened at 2010-01-06 20:47 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2927127&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: v 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Michael Zenke (mize) Assigned to: Nobody/Anonymous (nobody) Summary: Entreis in quota-Table not deleted when Mailbox is deleted Initial Comment: If you delete a mailbox it is correctly removed from the mailbox-table. Bu in the quota and quota2 tables the entries remain which may result in incorrect quota-calculation by, in my case dovecot, if you re-add the mailbox. I attach a patch which adds the required lines to delete.php. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 23:14 Message: Commited to SVN r830 with a small change: AFAIK the quota table may have two rows per mailbox (one for bytes, one for message count). Therefore I changed the if condition to check for >= 1 rows instead of exactly one row. I'll also merge this into the 2.3 branch - 2.3.1 will include this fix. Thanks for reporting and the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2927127&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 21:14:37
|
Bugs item #2927127, was opened at 2010-01-06 20:47 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2927127&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: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Zenke (mize) Assigned to: Nobody/Anonymous (nobody) Summary: Entreis in quota-Table not deleted when Mailbox is deleted Initial Comment: If you delete a mailbox it is correctly removed from the mailbox-table. Bu in the quota and quota2 tables the entries remain which may result in incorrect quota-calculation by, in my case dovecot, if you re-add the mailbox. I attach a patch which adds the required lines to delete.php. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 23:14 Message: Commited to SVN r830 with a small change: AFAIK the quota table may have two rows per mailbox (one for bytes, one for message count). Therefore I changed the if condition to check for >= 1 rows instead of exactly one row. I'll also merge this into the 2.3 branch - 2.3.1 will include this fix. Thanks for reporting and the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2927127&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 20:59:14
|
Bugs item #2987852, was opened at 2010-04-15 20:46 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2987852&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: Jonathan Rogers (jonner) Assigned to: Nobody/Anonymous (nobody) Summary: min_password_length ignored if current password check fails Initial Comment: In the user's change password form, if the current password field doesn't match the current password and the new password fields are shorter than min_password_length, the "Password is too short - requires 5 characters" message is displayed, but the password is changed anyway, so both checks are circumvented. I discovered that this is due to a bug in the way errors are counted. A patch to fix it is attached. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 22:59 Message: Oops, this shouldn't happen :-( Thanks for reporting and the patch! Fortunately only authentificated users can access the "change password" page, therefore the severity of this bug is limited. Fixed in SVN r829 (trunk), will be backported to the 2.3 branch also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2987852&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 11:49:14
|
Bugs item #2986880, was opened at 2010-04-14 03:21 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2986880&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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: oliver (n0d3) Assigned to: Nobody/Anonymous (nobody) Summary: Quta's stored as integers, should be bigint. Initial Comment: Quta's in the database may become to small soon. Currently quota's can be stored as any integer, and be multiplied externally. Thus having a quota of '10' could mean anything from 10 bytes, to 10GB depending on what multiplication factor is used in postfixadmin's config.inc.php. Postfix itself talks to the table via a select statement, that's just how it does that, and currently, with postfix the following query would be sent to postfix; postfix=> select quota from mailbox; quota ------- 10 (1 row) Doing the same external multiplication trick works, as long as it stays under 2^32, the maximum size for an integer; So for example: postfix=> select (quota *1024 *1024) from mailbox; ?column? ---------- 10485760 (1 row) Doesn't cause any issue really, so where is the problem? Well let's say this user is allowed to have some absurd quota, say 10GB. (Remember, Google already offers 1GB quotas and 2GB quotas exist for webmail providers. Having certain users with 10GB shouldn't be all that awkward. Trying a 10GB quota however fails horribly. postfix=> select (quota *1024 *1024 *1024) from mailbox; ERROR: integer out of range Changing the quota per user field from an Integer to a bigint solves the issue; ALTER TABLE mailbox ALTER quota TYPE bigint; postfix=> select (quota *1024 *1024 *1024) from mailbox; ?column? ------------- 10737418240 (1 row) In conclusion, this means quota's would have never worked if they where bigger then the type of the table, so using external multipliers would have only worked for anything not dependent on the SQL query (which postfix is). Actually, having an external multiplier is useless, though it allows for pretty printing. There could be many reasons actually been thought of to store the quota in bytes actually. Changing the type to bigint actually allows for absurd high quota's 9223372036854774784 or 8Exabyte on a per user level is maybe to high (even in a million years from now, I don't see anybody using 8Exabyte mailboxes) but could pose a problem, far far in the future for quota for domains or maxquota for all domains combined? So I would recommend, drop external multipliers, store quota's in bytes, pretty print them where needed and convert integers to bigints where needed (e.g. quota for per user, domain etc). ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 13:49 Message: As long as you use one of the usual multipication factors in config.inc.php ('1024000' or '1048576'), the mailbox quota is already stored in bytes. Also the quota fields are already bigint - IIRC already in the 2.3 release, for sure in SVN. Remaining issue: the domain-level quota ($CONF(maxquota)) is stored in MB instead of bytes. However, that's just used internally in postfixadmin, and changing it to bytes would probably cause more harm than good on upgrade. Therefore: - closing as "out of date" for the bigint field type because this is already implemented - closing as "wontfix" for changing domain-level maxquota to bytes instead of MB If you disagree or still have "small" integer quota fields with 2.3 or the upcoming 2.3.1 release (don't forget to run setup.php after upgrade), feel free to reopen this ticket ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2986880&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 11:30:43
|
Bugs item #2983354, was opened at 2010-04-07 19: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=2983354&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: Valkum (valkum) Assigned to: Nobody/Anonymous (nobody) Summary: dovecotpw with php Initial Comment: in association with my cli i have found something bad in my logs of an 2.3 Installation. In logfiles from Apache, not in log files from vhost, i found this: Enter new password: Retype new password: this is the stdout from dovecotpw. we have to fix it in any way. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 13:30 Message: Can you please re-test with the 2.3 branch (aka upcoming 2.3.1)? We now use pipes instead of temp files when calling dovecotpw - maybe this also fixes your issue... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2983354&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 11:26:12
|
Patches item #2886618, was opened at 2009-10-26 18:58 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&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: Accepted Priority: 5 Private: No Submitted By: Iñaki R. (virtualminds) Assigned to: Nobody/Anonymous (nobody) Summary: ADDITION: Hooks for create, delete and edit cyrus mailboxes Initial Comment: Hooks for create, delete and edit cyrus mailboxes. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-18 13:26 Message: OK, changed path commited. ---------------------------------------------------------------------- Comment By: Iñaki R. (virtualminds) Date: 2010-05-17 00:58 Message: No problem, It seems me better store it under /etc directory :D Greetings ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-05-17 00:46 Message: Reopening to clarify a small issue ;-) Your scripts use the config file /var/www/postfixadmin/ADDITIONS/cyrus/cyrus.conf while many other scripts use /etc/mail/postfixadmin. Do you have any objections against changing the path in the scripts? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-03-24 15:07 Message: added to svn; as per changeset 817, thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-16 22:58:02
|
Patches item #2886618, was opened at 2009-10-26 18:58 Message generated for change (Comment added) made by virtualminds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&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: Accepted Priority: 5 Private: No Submitted By: Iñaki R. (virtualminds) Assigned to: Nobody/Anonymous (nobody) Summary: ADDITION: Hooks for create, delete and edit cyrus mailboxes Initial Comment: Hooks for create, delete and edit cyrus mailboxes. ---------------------------------------------------------------------- >Comment By: Iñaki R. (virtualminds) Date: 2010-05-17 00:58 Message: No problem, It seems me better store it under /etc directory :D Greetings ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-05-17 00:46 Message: Reopening to clarify a small issue ;-) Your scripts use the config file /var/www/postfixadmin/ADDITIONS/cyrus/cyrus.conf while many other scripts use /etc/mail/postfixadmin. Do you have any objections against changing the path in the scripts? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-03-24 15:07 Message: added to svn; as per changeset 817, thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-16 22:46:36
|
Patches item #2886618, was opened at 2009-10-26 18:58 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&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: Accepted Priority: 5 Private: No Submitted By: Iñaki R. (virtualminds) Assigned to: Nobody/Anonymous (nobody) Summary: ADDITION: Hooks for create, delete and edit cyrus mailboxes Initial Comment: Hooks for create, delete and edit cyrus mailboxes. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-17 00:46 Message: Reopening to clarify a small issue ;-) Your scripts use the config file /var/www/postfixadmin/ADDITIONS/cyrus/cyrus.conf while many other scripts use /etc/mail/postfixadmin. Do you have any objections against changing the path in the scripts? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-03-24 15:07 Message: added to svn; as per changeset 817, thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2886618&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-16 22:02:20
|
Bugs item #2976010, was opened at 2010-03-24 17:41 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2976010&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: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: edit-alias.php backwards in_array arguments Initial Comment: 144 if(in_array($orig_alias_list, $fAddress)) { should be 144 if(in_array($fAddress, $orig_alias_list)) { and seems to still be this way in the current SVN version. [r816, ln140] Also, there seems to be a flaw in the logic of this file where if special_alias_control = NO the mailbox alias is removed, but is only restored if alias_control_admin = NO as well which essentially ~does~ let the domain admin control the default mailbox alias by virtue of it being removed if they do not add it back manually. Lines relevant to the above are 73 and 142 in v2.3, 68 and 138 in SVN r816 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2010-05-17 00:02 Message: The in_array issue was fixed in SVN r818. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2976010&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 14:27:55
|
Bugs item #2999963, was opened at 2010-05-11 12:52 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&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: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: saki () Assigned to: Nobody/Anonymous (nobody) Summary: Auto-response message has character encoding problem Initial Comment: I'm using Postfix Admin 2.2.1.1. When I put ISO-8859-2 (latin2) characters to the auto-response message, there will be accent (encoding) problem in the response mails. should be: Házonkívül leszek. árvíztűrő tükörfúgógép. but in the mail I see In Squirrelmail: H??zonk??v??l leszek. ??rv??zt??r?? t??k??rf??g??g??p. In Thunderbird: HĂĄzonkĂvĂźl leszek. ĂĄrvĂztĹąrĹ� tĂźkĂśrfĂşgĂłgĂŠp. I've checked the database, the vacation table stores the auto-response message perfectly! The encoding problem must be during the mail sending. Thank you so much in advance to solve this! ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2010-05-11 14:27 Message: Any chance you can upgrade to a later version of vacation.pl ? ---------------------------------------------------------------------- Comment By: saki () Date: 2010-05-11 14:12 Message: In the vacation.pl file I found this: "Virtual Vacation 3.1" and I found a "vacation.2211.patch.txt" file in the vacation folder. ---------------------------------------------------------------------- Comment By: saki () Date: 2010-05-11 14:08 Message: Debug file: ====== 2010/05/11 16:05:36 ====== [STRIP RECIPIENTS]: | <66c...@ma...> | SE...@SE... ====== 2010/05/11 16:05:36 ====== [FOUND VACATION]: | <66c...@ma...> | SE...@SE... | SE...@SE... | SE...@SE... ====== 2010/05/11 16:05:36 ====== [SEND RESPONSE] for <66c...@ma...>: | FROM: SE...@SE... (orig_to: SE...@SE...) | TO: SE...@SE... | VACATION SUBJECT: HázonkÃvül | VACATION BODY: Nem leszek itt. ÃrvÃztűrÅ tükörfúrógép. As you can see, the auto response has the character encoding problem.:( ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-05-11 13:21 Message: Hi, The vacation.pl script uses the Perl module Mail::Sendmail to compose repsonses. I believe this should handle the utf8 encoding of the mail. Can you enable debugging on your vacation.pl script and find a line in the log file that looks like : "Will send vacation response for "..... and let me know whether this contains the 'correct' text or whether it's been broken at this point? Also knowing what version of the vacation.pl script you are using would be helpful. My checked out version has "Revision: 757" near the top. thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 14:12:46
|
Bugs item #2999963, was opened at 2010-05-11 12:52 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&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: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: saki () Assigned to: Nobody/Anonymous (nobody) Summary: Auto-response message has character encoding problem Initial Comment: I'm using Postfix Admin 2.2.1.1. When I put ISO-8859-2 (latin2) characters to the auto-response message, there will be accent (encoding) problem in the response mails. should be: Házonkívül leszek. árvíztűrő tükörfúgógép. but in the mail I see In Squirrelmail: H??zonk??v??l leszek. ??rv??zt??r?? t??k??rf??g??g??p. In Thunderbird: HĂĄzonkĂvĂźl leszek. ĂĄrvĂztĹąrĹ� tĂźkĂśrfĂşgĂłgĂŠp. I've checked the database, the vacation table stores the auto-response message perfectly! The encoding problem must be during the mail sending. Thank you so much in advance to solve this! ---------------------------------------------------------------------- >Comment By: saki () Date: 2010-05-11 14:12 Message: In the vacation.pl file I found this: "Virtual Vacation 3.1" and I found a "vacation.2211.patch.txt" file in the vacation folder. ---------------------------------------------------------------------- Comment By: saki () Date: 2010-05-11 14:08 Message: Debug file: ====== 2010/05/11 16:05:36 ====== [STRIP RECIPIENTS]: | <66c...@ma...> | SE...@SE... ====== 2010/05/11 16:05:36 ====== [FOUND VACATION]: | <66c...@ma...> | SE...@SE... | SE...@SE... | SE...@SE... ====== 2010/05/11 16:05:36 ====== [SEND RESPONSE] for <66c...@ma...>: | FROM: SE...@SE... (orig_to: SE...@SE...) | TO: SE...@SE... | VACATION SUBJECT: HázonkÃvül | VACATION BODY: Nem leszek itt. ÃrvÃztűrÅ tükörfúrógép. As you can see, the auto response has the character encoding problem.:( ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-05-11 13:21 Message: Hi, The vacation.pl script uses the Perl module Mail::Sendmail to compose repsonses. I believe this should handle the utf8 encoding of the mail. Can you enable debugging on your vacation.pl script and find a line in the log file that looks like : "Will send vacation response for "..... and let me know whether this contains the 'correct' text or whether it's been broken at this point? Also knowing what version of the vacation.pl script you are using would be helpful. My checked out version has "Revision: 757" near the top. thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 14:08:56
|
Bugs item #2999963, was opened at 2010-05-11 12:52 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&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: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: saki () Assigned to: Nobody/Anonymous (nobody) Summary: Auto-response message has character encoding problem Initial Comment: I'm using Postfix Admin 2.2.1.1. When I put ISO-8859-2 (latin2) characters to the auto-response message, there will be accent (encoding) problem in the response mails. should be: Házonkívül leszek. árvíztűrő tükörfúgógép. but in the mail I see In Squirrelmail: H??zonk??v??l leszek. ??rv??zt??r?? t??k??rf??g??g??p. In Thunderbird: HĂĄzonkĂvĂźl leszek. ĂĄrvĂztĹąrĹ� tĂźkĂśrfĂşgĂłgĂŠp. I've checked the database, the vacation table stores the auto-response message perfectly! The encoding problem must be during the mail sending. Thank you so much in advance to solve this! ---------------------------------------------------------------------- >Comment By: saki () Date: 2010-05-11 14:08 Message: Debug file: ====== 2010/05/11 16:05:36 ====== [STRIP RECIPIENTS]: | <66c...@ma...> | SE...@SE... ====== 2010/05/11 16:05:36 ====== [FOUND VACATION]: | <66c...@ma...> | SE...@SE... | SE...@SE... | SE...@SE... ====== 2010/05/11 16:05:36 ====== [SEND RESPONSE] for <66c...@ma...>: | FROM: SE...@SE... (orig_to: SE...@SE...) | TO: SE...@SE... | VACATION SUBJECT: HázonkÃvül | VACATION BODY: Nem leszek itt. ÃrvÃztűrÅ tükörfúrógép. As you can see, the auto response has the character encoding problem.:( ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-05-11 13:21 Message: Hi, The vacation.pl script uses the Perl module Mail::Sendmail to compose repsonses. I believe this should handle the utf8 encoding of the mail. Can you enable debugging on your vacation.pl script and find a line in the log file that looks like : "Will send vacation response for "..... and let me know whether this contains the 'correct' text or whether it's been broken at this point? Also knowing what version of the vacation.pl script you are using would be helpful. My checked out version has "Revision: 757" near the top. thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 13:21:58
|
Bugs item #2999963, was opened at 2010-05-11 12:52 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&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: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: saki () Assigned to: Nobody/Anonymous (nobody) Summary: Auto-response message has character encoding problem Initial Comment: I'm using Postfix Admin 2.2.1.1. When I put ISO-8859-2 (latin2) characters to the auto-response message, there will be accent (encoding) problem in the response mails. should be: Házonkívül leszek. árvíztűrő tükörfúgógép. but in the mail I see In Squirrelmail: H??zonk??v??l leszek. ??rv??zt??r?? t??k??rf??g??g??p. In Thunderbird: HĂĄzonkĂvĂźl leszek. ĂĄrvĂztĹąrĹ� tĂźkĂśrfĂşgĂłgĂŠp. I've checked the database, the vacation table stores the auto-response message perfectly! The encoding problem must be during the mail sending. Thank you so much in advance to solve this! ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2010-05-11 13:21 Message: Hi, The vacation.pl script uses the Perl module Mail::Sendmail to compose repsonses. I believe this should handle the utf8 encoding of the mail. Can you enable debugging on your vacation.pl script and find a line in the log file that looks like : "Will send vacation response for "..... and let me know whether this contains the 'correct' text or whether it's been broken at this point? Also knowing what version of the vacation.pl script you are using would be helpful. My checked out version has "Revision: 757" near the top. thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 12:52:50
|
Bugs item #2999963, was opened at 2010-05-11 12:52 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&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: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Auto-response message has character encoding problem Initial Comment: I'm using Postfix Admin 2.2.1.1. When I put ISO-8859-2 (latin2) characters to the auto-response message, there will be accent (encoding) problem in the response mails. should be: Házonkívül leszek. árvíztűrő tükörfúgógép. but in the mail I see In Squirrelmail: H??zonk??v??l leszek. ??rv??zt??r?? t??k??rf??g??g??p. In Thunderbird: HĂĄzonkĂvĂźl leszek. ĂĄrvĂztĹąrĹ� tĂźkĂśrfĂşgĂłgĂŠp. I've checked the database, the vacation table stores the auto-response message perfectly! The encoding problem must be during the mail sending. Thank you so much in advance to solve this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2999963&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-30 12:23:08
|
Bugs item #2994697, was opened at 2010-04-30 11:48 Message generated for change (Settings changed) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&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: Invalid Priority: 5 Private: No Submitted By: Peter Semisotov (petkin) Assigned to: Nobody/Anonymous (nobody) Summary: php >= 5.3: ereg() are deprecated Initial Comment: As described in this post "php >= 5.3: some functions are deprecated. - ID: 2818862" but now in config.inc.php line 19 ereg() deprecated postfixadmin 2.3, from Freebsd ports ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-04-30 12:22 Message: The ereg() calls have already been removed from what's in SVN... ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-04-30 12:22 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: Peter Semisotov (petkin) Date: 2010-04-30 11:51 Message: After i upgrade today php to 5.3 i have this error fix it by replace in /usr/local/www/postfixadmin/config.inc.php line 19 from if (ereg ("config.inc.php", $_SERVER['PHP_SELF'])) to if (preg_match ("/config.inc.php/", $_SERVER['PHP_SELF'])) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-30 12:22:57
|
Bugs item #2994697, was opened at 2010-04-30 11:48 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&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: Invalid Priority: 5 Private: No Submitted By: Peter Semisotov (petkin) Assigned to: Nobody/Anonymous (nobody) Summary: php >= 5.3: ereg() are deprecated Initial Comment: As described in this post "php >= 5.3: some functions are deprecated. - ID: 2818862" but now in config.inc.php line 19 ereg() deprecated postfixadmin 2.3, from Freebsd ports ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2010-04-30 12:22 Message: The ereg() calls have already been removed from what's in SVN... ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-04-30 12:22 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: Peter Semisotov (petkin) Date: 2010-04-30 11:51 Message: After i upgrade today php to 5.3 i have this error fix it by replace in /usr/local/www/postfixadmin/config.inc.php line 19 from if (ereg ("config.inc.php", $_SERVER['PHP_SELF'])) to if (preg_match ("/config.inc.php/", $_SERVER['PHP_SELF'])) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-30 11:51:55
|
Bugs item #2994697, was opened at 2010-04-30 14:48 Message generated for change (Comment added) made by petkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&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: Peter Semisotov (petkin) Assigned to: Nobody/Anonymous (nobody) Summary: php >= 5.3: ereg() are deprecated Initial Comment: As described in this post "php >= 5.3: some functions are deprecated. - ID: 2818862" but now in config.inc.php line 19 ereg() deprecated postfixadmin 2.3, from Freebsd ports ---------------------------------------------------------------------- >Comment By: Peter Semisotov (petkin) Date: 2010-04-30 14:51 Message: After i upgrade today php to 5.3 i have this error fix it by replace in /usr/local/www/postfixadmin/config.inc.php line 19 from if (ereg ("config.inc.php", $_SERVER['PHP_SELF'])) to if (preg_match ("/config.inc.php/", $_SERVER['PHP_SELF'])) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-30 11:48:59
|
Bugs item #2994697, was opened at 2010-04-30 14:48 Message generated for change (Tracker Item Submitted) made by petkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&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: Peter Semisotov (petkin) Assigned to: Nobody/Anonymous (nobody) Summary: php >= 5.3: ereg() are deprecated Initial Comment: As described in this post "php >= 5.3: some functions are deprecated. - ID: 2818862" but now in config.inc.php line 19 ereg() deprecated postfixadmin 2.3, from Freebsd ports ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2994697&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-19 22:26:30
|
Patches item #2976213, was opened at 2010-03-24 23:42 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&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: Accepted Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: maildir name hook Initial Comment: Regarding the hook to define a function to create a custom maildir: https://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/3493439 I've gone ahead and done so. One directive added to $CONF, one function added to functions.inc.php, and a modification to create-mailbox.php to implement it. Generated based on v2.3 ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2010-04-19 22:26 Message: Thank you - merged in changeset 819 ---------------------------------------------------------------------- Comment By: W. Rossmann () Date: 2010-04-19 17:22 Message: Re-written based on the latest version. [r818] The line numbering might be a bit squiffy in some of my patches since I have a habit of patching overtop my patchy code. Let me know if you have trouble with any of them and I'll re-write over a fresh version from SVN. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-04-16 21:54 Message: Hi, I'd suggest, that : a) The config parameter is set to either NO or the name of a function to be called. b) Your code then does a if($CONF['maildir_hook_function'] != NO) { $maildir_hook_function($params....); } type thing. This would allow many different functions to be written (And all merged, perhaps) which do hashing or whatever in different ways). Also - any chance you could recreate the patch based on the latest version in SVN? It doesn't apply cleanly at the moment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-19 17:22:19
|
Patches item #2976213, was opened at 2010-03-24 23:42 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&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: Open Resolution: None Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: maildir name hook Initial Comment: Regarding the hook to define a function to create a custom maildir: https://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/3493439 I've gone ahead and done so. One directive added to $CONF, one function added to functions.inc.php, and a modification to create-mailbox.php to implement it. Generated based on v2.3 ---------------------------------------------------------------------- >Comment By: W. Rossmann () Date: 2010-04-19 17:22 Message: Re-written based on the latest version. [r818] The line numbering might be a bit squiffy in some of my patches since I have a habit of patching overtop my patchy code. Let me know if you have trouble with any of them and I'll re-write over a fresh version from SVN. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2010-04-16 21:54 Message: Hi, I'd suggest, that : a) The config parameter is set to either NO or the name of a function to be called. b) Your code then does a if($CONF['maildir_hook_function'] != NO) { $maildir_hook_function($params....); } type thing. This would allow many different functions to be written (And all merged, perhaps) which do hashing or whatever in different ways). Also - any chance you could recreate the patch based on the latest version in SVN? It doesn't apply cleanly at the moment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-16 21:54:43
|
Patches item #2976213, was opened at 2010-03-24 23:42 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&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: Open Resolution: None Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: maildir name hook Initial Comment: Regarding the hook to define a function to create a custom maildir: https://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/3493439 I've gone ahead and done so. One directive added to $CONF, one function added to functions.inc.php, and a modification to create-mailbox.php to implement it. Generated based on v2.3 ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2010-04-16 21:54 Message: Hi, I'd suggest, that : a) The config parameter is set to either NO or the name of a function to be called. b) Your code then does a if($CONF['maildir_hook_function'] != NO) { $maildir_hook_function($params....); } type thing. This would allow many different functions to be written (And all merged, perhaps) which do hashing or whatever in different ways). Also - any chance you could recreate the patch based on the latest version in SVN? It doesn't apply cleanly at the moment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2976213&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2010-04-16 17:44:07
|
Patches item #2988459, was opened at 2010-04-16 17:44 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2988459&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: Open Resolution: None Priority: 5 Private: No Submitted By: W. Rossmann () Assigned to: Nobody/Anonymous (nobody) Summary: control disabled/unlimited quotas Initial Comment: This patch allows you to control the level of admin that is permitted to set quotas of -1 [disabled] or 0 [unlimited] as in some cases you do not want users to be permitted to use as much disk space as they wish. [ie. a hosted mail provider] The default state is to allow both domain and global admins to use any quota setting, the next level of control disallows domain admins, and the highest level disallows both domain and global admins. As always, those who can edit the config manually can set any quota they wish. Files changed: - config.inc.php: added $CONF['allow_quota_disabled'] and $CONF['allow_quota_unlimited'] - functions.inc.php: rewrite of check_quota() to accomodate extra checks/functionality * - edit-mailbox.php: fix an issue that arises where a mailbox password could not be edited while the quota is set to a restricted value. Edited to only execute check_quota() if the quota has changed. Notes: - the error text that is raised, "The quota that you specified is to high!" becomes misleading. You may wish to edit $PALANG['pCreate_mailbox_quota_text_error'] and $PALANG['pEdit_mailbox_quota_text_error'] to something more general. ie. "The quota that you specified is invalid." - restricting disabled [-1] quotas may not be desirable as this will interfere with forward-only domains and disallow forward-only mailboxes. ** - patches generated using v2.3, though code up to r816 appears to be the same. * I have also included a baseline rewrite of check_quota() with none of the code from my patches, including comments about my reasoning for the change. ** Special thanks to cboltz for some helpful suggestions, and getting me to understand the reasoning for a domain maxquota of -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2988459&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
