postfixadmin-devel — Postfix Admin development talk - users are also welcome

Re: [Postfixadmin-devel] Cutom Admin role

[Christian B. <pos...@cb...>]

Hello,

(you subscribed with a different address, therefore your mail was 
hanging in the moderation queue.)

Am Sonntag, 17. April 2011 schrieb Nasser Heidari:
> Is it possible to create a user who only have access to add or remove
> alias on a domain?

Not with our current permission model, and you are the first one who 
asks for an alias-only admin.

You can restrict an admin to a domain, but he has permissions to 
add/edit/remove mailboxes and aliases (and alias domains if he has 
permissions for at least 2 domains).

There might be a workaround:
If the domain will only have aliases (no mailboxes), limit the number of 
mailboxes to 0 for the domain. Then he'll not be able to create 
mailboxes because the domain is not allowed to have any mailboxes ;-)

BTW: What is your usecase? (I'd like to understand better why you are 
asking for an alias-only admin.)


Regards,

Christian Boltz
-- 
"DOS=HIGH ...I knew it was on something!"
                    (UNIX user, while reading C:\CONFIG.SYS)

[Postfixadmin-devel] Cutom Admin role

[Nasser H. <na...@ra...>]

Hello, 
Is it possible to create a user who only have access to add or remove
alias on a domain?

Regards,
Nasser

Re: [Postfixadmin-devel] Core Tables

[Rudi F. <rud...@go...>]

Plugins are extensions to our core support. Like squirrelmail 
integeraten etc. This plugins can be maintained by third parties.

The layout of core_fields could be

| id | name     | module (core modules | translation_id |
|    | (unique)| mailbox, alias, domain, | (DB based      |
|    |          | vacation or plugins)   |translation)  |
+----+----------+-------------------------+----------------+
|  1 | owner    | domain                  | 1              |
|  2 | streetm  | mailbox                 | 2              |
|  3 | streeta  |alias                   | 3              |

field_owner
| id | value       |
+----+-------------+
| 65 | Steve Jobbs |

field_streetm
| id | value       |
+----+-------------+
| 54 | Hans Zimmer |

translation
| id | tid | language_key | string          |
+----+-----+--------------+-----------------+
| 1  | 1   | de           | Domain Besitzer |
| 2  | 1   | en           | Domain Owner    |


core_plugins
| id | name                      | path           | enabled |
+----+---------------------------+----------------+---------+
| 1  | squirrelmail integeration | plugins/sqmail | 1       |



To avoid security holes we can define that only admin with id 1 (the 
first created super admin) can edit special settings.

greetz Rudi


Am 10.04.2011 18:37, schrieb Christian Boltz:
> Hello,
>
> Am Sonntag, 10. April 2011 schrieb Rudi Floren:
>> One target of 3.0 is a new path system and a admin config backend.
>>
>> for this purpose i would like to add some core tables.
>> These tables would include the plugin system. which plugins are
>> enabled  etc.
> Define "plugin", please ;-)
>
> If you are talking about enabling/disabling things like fetchmail,
> sending a mail (to single recipient or to all) etc.: I'm not sure if I
> like the idea in the web interface (for security reasons).
>
> At the moment, we have those settings in config.inc.php which means
> filesystem permissions are required to change those settings.
> With those settings in the database, it would be possible to change them
> remotely. (I hope we don't have a security problem somewhere, but you
> never know.)
>
> BTW: I have several servers where $other_person has (and needs)
> superadmin permissions (because he needs to add domains and domain
> admins), but I don't want this $other_person to change any config
> options that are now in config.*.php.
>
> I'd prefer a script that gives me some PHP code with $CONF options and
> says
>      "Add this to your config.local.php"
>
>> And the most wanted feature user defined fields.
>> So we can build querys which include the user defined fields.
> In theory, we could add some "customX" fields. However, they need labels
> etc. so it's unavoidable that someone has to edit translations,
> templates etc.
>
> In practise, we should use $struct (see DomainHandler) and provide a
> hook to extend/change it. That's the most flexible way.
>
> Users would have to add their custom fields ("x_...") to the database
> structure, but I don't see a real problem with this. It's even an
> advantage because they can choose the field type they really need, and
> are not limited to the number of predefined custom fields we would
> provide.
>
> Hmm, thinking about it:
> In theory, we could manage the additional fields in the database (in a
> table like $struct) and even provide an interface to add fields.
> However the precondition for this is clearly that we have a $struct for
> all tables and that it is used.
> (In practise, I still prefer to have such things in the filesystem.)
>
> Note: the $struct layout isn't final yet - I'm thinking of adding
> default values, labels etc. to it to have everything in one place.
> That would also be an advantage when it comes to additional fields.
>
>> Some dieas of names are core_plugins, core_admins, core_fields etc.
> If you still think your way is a good idea after reading my comments ;-)
> please give some examples how these tables would look like and what they
> would contain.
>
>
> Another thing:
> I'd like to reserve the "postfixadmin-$version" branch names for bugfix
> branches of major releases, similar to the 2.3 branch.
>
> Please rename the postfixadmin-3.0 branch to something that does not
> include a version number (maybe "postfixadmin-next", "postfixadmin-
> playground" or "postfixadmin-super-duper-features" ;-)  And please do
> this soon so that not too many commit messages contain an outdated
> branch name.
>
> I could do the renaming myself, but that would give you some trouble if
> you have uncommited changes. Therefore I'm asking you to do it yourself.
>
> That said: I'd still prefer if you do your changes directly in trunk
> (unless you totally break something). This would avoid that you get
> merge conflicts afterwards ;-) which are probably unavoidable as soon as
> I move most code to model/*.
>
>
> Regards,
>
> Christian Boltz

Re: [Postfixadmin-devel] Core Tables

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 10. April 2011 schrieb Rudi Floren:
> One target of 3.0 is a new path system and a admin config backend.
> 
> for this purpose i would like to add some core tables.
> These tables would include the plugin system. which plugins are
> enabled  etc.

Define "plugin", please ;-)

If you are talking about enabling/disabling things like fetchmail, 
sending a mail (to single recipient or to all) etc.: I'm not sure if I 
like the idea in the web interface (for security reasons).

At the moment, we have those settings in config.inc.php which means 
filesystem permissions are required to change those settings.
With those settings in the database, it would be possible to change them 
remotely. (I hope we don't have a security problem somewhere, but you 
never know.)

BTW: I have several servers where $other_person has (and needs) 
superadmin permissions (because he needs to add domains and domain 
admins), but I don't want this $other_person to change any config 
options that are now in config.*.php.

I'd prefer a script that gives me some PHP code with $CONF options and 
says 
    "Add this to your config.local.php"

> And the most wanted feature user defined fields.
> So we can build querys which include the user defined fields.

In theory, we could add some "customX" fields. However, they need labels 
etc. so it's unavoidable that someone has to edit translations, 
templates etc.

In practise, we should use $struct (see DomainHandler) and provide a 
hook to extend/change it. That's the most flexible way.

Users would have to add their custom fields ("x_...") to the database 
structure, but I don't see a real problem with this. It's even an 
advantage because they can choose the field type they really need, and 
are not limited to the number of predefined custom fields we would 
provide.

Hmm, thinking about it:
In theory, we could manage the additional fields in the database (in a 
table like $struct) and even provide an interface to add fields.
However the precondition for this is clearly that we have a $struct for 
all tables and that it is used.
(In practise, I still prefer to have such things in the filesystem.)

Note: the $struct layout isn't final yet - I'm thinking of adding 
default values, labels etc. to it to have everything in one place.
That would also be an advantage when it comes to additional fields.

> Some dieas of names are core_plugins, core_admins, core_fields etc.

If you still think your way is a good idea after reading my comments ;-) 
please give some examples how these tables would look like and what they 
would contain.


Another thing: 
I'd like to reserve the "postfixadmin-$version" branch names for bugfix 
branches of major releases, similar to the 2.3 branch.

Please rename the postfixadmin-3.0 branch to something that does not 
include a version number (maybe "postfixadmin-next", "postfixadmin-
playground" or "postfixadmin-super-duper-features" ;-)  And please do 
this soon so that not too many commit messages contain an outdated 
branch name.

I could do the renaming myself, but that would give you some trouble if 
you have uncommited changes. Therefore I'm asking you to do it yourself.

That said: I'd still prefer if you do your changes directly in trunk 
(unless you totally break something). This would avoid that you get 
merge conflicts afterwards ;-) which are probably unavoidable as soon as 
I move most code to model/*.


Regards,

Christian Boltz
-- 
Der Vergleich hinkt wie eine Schnecke mit Holzbein ;)   [David Haller]

[Postfixadmin-devel] Core Tables

[Rudi F. <rud...@go...>]

One target of 3.0 is a new path system and a admin config backend.

for this purpose i would like to add some core tables.
These tables would include the plugin system. which plugins are enabled 
etc. And the most wanted feature user defined fields.
So we can build querys which include the user defined fields.

what do you think about my idea?

Some dieas of names are core_plugins, core_admins, core_fields etc.

greetz Rudi

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Tanstaafl <tan...@li...>]

On 4/8/2011 2:21 PM, Christian Boltz wrote:
> Am Freitag, 8. April 2011 schrieb Tanstaafl:
>> Why not just add one special table for *all* special fields?

> Because it makes things more difficult:
> - you have to JOIN two tables in SELECT queries (which will become a 
>   pain at least for listing mailboxes - it already has an 
>   interesting[tm] query)
> - you have to write to two tables in INSERT, UPDATE and DELETE
> - things will become really funny if you want to extend more than one 
>   table
> 
> Trust me: you (usually) don't want that ;-)

I'd be happy to just take your word for it... but thanks also for the
explanation as to why...

:)

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Christian B. <pos...@cb...>]

Hello,

Am Freitag, 8. April 2011 schrieb Tanstaafl:
> On 2011-04-07 6:40 PM, David Goodwin wrote:
> > People keep asking for additional fields, but I'm not really sure
> > it's something we can ever support in a flexible enough way to
> > satisfy anyone.

I think we can make it very flexible - guess why I want to use arrays 
like in fetchmail.php everywhere ;-)  (and send me some free time if you 
have too much *g* so that I can get it done)

> > I'm happy to have a rule that fields starting with x_ are
> > 'reserved' for local site customisations. We should include a note
> > in one of the files in svn to make it official.
> 
> Why not just add one special table for *all* special fields?

Because it makes things more difficult:
- you have to JOIN two tables in SELECT queries (which will become a 
  pain at least for listing mailboxes - it already has an 
  interesting[tm] query)
- you have to write to two tables in INSERT, UPDATE and DELETE
- things will become really funny if you want to extend more than one 
  table

Trust me: you (usually) don't want that ;-)


However, you brought up a good point and I'll add another rule:

If you want to create an additional table, use a name starting with 
"x_". 
Within that table, you can use any field and index names you want, and 
may also create unique keys. If you use PostgreSQL, names for indexes 
and unique keys must start with "x_".
Avoid foreign keys to PostfixAdmin's default tables if possible.


Regards,

Christian Boltz
-- 
[CR/LF]  Beides sind uralte Begriffe, die noch aus der Zeit der
Schreibmaschinen stammen (das sind so komische Geräte mit denen man
Buchstaben und Zahlen auf Papier bekam, ohne das ein Computer und ein
Drucker dazwischen hing:-))).   [Nico Jochens in suse-linux]

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Luigi R. <li...@lu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tanstaafl said the following on 08/04/11 14:13:

> Why not just add one special table for *all* special fields?

Back to square one: how should be called one or more special table like tis in
order not to break compatibility and automatic structure upgrade?



Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

The last time somebody said, "I find I can write much better with a word
processor.",
I replied, "They used to say the same thing about drugs."
    --Roy Blount, Jr.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2fAMUACgkQ3kWu7Tfl6ZRhlgCfY2zRPhExxAhYvHYsD0C/QCFg
2eYAn10DHOsuf1vhLTc/zlHYsZeMyxth
=miRh
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Tanstaafl <tan...@li...>]

On 2011-04-07 6:40 PM, David Goodwin wrote:
> People keep asking for additional fields, but I'm not really sure it's something we can ever support in a flexible enough way to satisfy anyone. 
> 
> I'm happy to have a rule that fields starting with x_ are 'reserved' for local site customisations. We should include a note in one of the files in svn to make it official. 

Why not just add one special table for *all* special fields?

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Luigi R. <li...@lu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Boltz said the following on 08/04/11 00:32:

> - you can use any fieldname starting with "x_"

That's exactly what I was thinking about and would be perfect.

Thank you all!


Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

The cinema is little more than a fad. It's canned drama. What
audiences really want to see is flesh and blood on the stage.
       --Charlie Chaplin, 1916
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2eidwACgkQ3kWu7Tfl6ZQTZQCdGF2+6vW7u45mv7rd0C051F/D
9nMAnRhTvS0J5uTV8PtA36j7ZAkc8Ae1
=bFUm
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[David G. <da...@co...>]

People keep asking for additional fields, but I'm not really sure it's something we can ever support in a flexible enough way to satisfy anyone. 

I'm happy to have a rule that fields starting with x_ are 'reserved' for local site customisations. We should include a note in one of the files in svn to make it official. 

David. 

David Goodwin 
Pale Purple Ltd. 
http://www.palepurple.co.uk
0845 0046746
07792 380669

On 7 Apr 2011, at 23:32, Christian Boltz <pos...@cb...> wrote:

> Hello,
> 
> Am Mittwoch, 6. April 2011 schrieb Luigi Rosa:
>> I wish to add a couple of fields to mailbox table for administrative
>> purposes.
>> 
>> Is there a correct way to select the names of the fields in order not
>> to break the database structure update process?
> 
> We don't have a policy on this - at least until now.
> I guess we should define one...
> 
> Just as idea: (I'm open to feedback and/or better ideas ;-)
> - you can use any fieldname starting with "x_"
> - you can create indexes if needed (also prefix them with x_ (or
>  tablename_x_ for PostgreSQL)
> - avoid creating unique indexes and foreign keys if possible (they could 
>  make scheme changes difficult)
> 
> Would that be OK for you?
> 
> @David: what do you think?
> 
> 
> Regards,
> 
> Christian Boltz
> -- 
>> The issue here is the one of disk space... How do you know before hand
>> there is enough disk space in /boot and /lib?
> Err, ask Mr. Filesystem and, given your hd has turned ROM because it's
> full, fail gracefully?
> [> Marcus Meissner and Wolfgang Woehl in opensuse-factory]
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] Adding arbitrary field to mailbox table

[Christian B. <pos...@cb...>]

Hello,

Am Mittwoch, 6. April 2011 schrieb Luigi Rosa:
> I wish to add a couple of fields to mailbox table for administrative
> purposes.
> 
> Is there a correct way to select the names of the fields in order not
> to break the database structure update process?

We don't have a policy on this - at least until now.
I guess we should define one...

Just as idea: (I'm open to feedback and/or better ideas ;-)
- you can use any fieldname starting with "x_"
- you can create indexes if needed (also prefix them with x_ (or
  tablename_x_ for PostgreSQL)
- avoid creating unique indexes and foreign keys if possible (they could 
  make scheme changes difficult)

Would that be OK for you?

@David: what do you think?


Regards,

Christian Boltz
-- 
> The issue here is the one of disk space... How do you know before hand
> there is enough disk space in /boot and /lib?
Err, ask Mr. Filesystem and, given your hd has turned ROM because it's
full, fail gracefully?
[> Marcus Meissner and Wolfgang Woehl in opensuse-factory]

[Postfixadmin-devel] Adding arbitrary field to mailbox table

[Luigi R. <li...@lu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I wish to add a couple of fields to mailbox table for administrative purposes.

Is there a correct way to select the names of the fields in order not to break
the database structure update process?

Thank you in advance.




Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

Immanuel Kant but Kubla Khan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2cKBsACgkQ3kWu7Tfl6ZTSgACgnW1kH9srctUfgMSBrtqh790Y
OkQAn0j4iRTcHIhEum+6J0/BG05w2Bbz
=EkDh
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

Here is an german schema of an exim database.
http://developer.gauner.org/ispmail-exim/
we only need the config files. our database schema is right.

Should be part of our ExampleConfig Wiki Category.
Am 07.03.2011 03:30, schrieb David Goodwin:
>> Another point is the start of a 3.0 branch.
>> The main goals are:
>> *Split handlers in  model and controller
>> *extract db function into special db layer.
>> *refactoring of function.inc.php. It should only have helper functions
>> like array_remove etc.
>> *new path system for support the mvc concept as good as possible.
>> *user defined fields in database and backend. (see: CCK in drupal 6)
>> *better setup, with automatic config.local.php creation
>> *better support of PFA-CLI
>> *upgrade from 2.2, 2.3 and 2.4 to 3.0
>> *some feature request in our tracker
>>
>> What do you think?
> A better idea would be to support e.g. exim as well.... but I have no knowledge of exim.
>
>
>
> David.
>

Re: [Postfixadmin-devel] PFA v3

[David G. <da...@co...>]

> 
> Another point is the start of a 3.0 branch.
> The main goals are:
> *Split handlers in  model and controller
> *extract db function into special db layer.
> *refactoring of function.inc.php. It should only have helper functions
> like array_remove etc.
> *new path system for support the mvc concept as good as possible.
> *user defined fields in database and backend. (see: CCK in drupal 6)
> *better setup, with automatic config.local.php creation
> *better support of PFA-CLI
> *upgrade from 2.2, 2.3 and 2.4 to 3.0
> *some feature request in our tracker
> 
> What do you think?

A better idea would be to support e.g. exim as well.... but I have no knowledge of exim.



David.

Re: [Postfixadmin-devel] 2.3.3 release?

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 6. März 2011 schrieb Rudi Floren:
> look at rev. 981
> I think i have fixed the logging problem.

Yes, but that's SVN trunk.

Your change is very good as long-term solution, but too intrusive for 
backporting it to the 2.3 branch IMHO.

@Tanstaafl: The change basically is to drop large parts of 
edit-vacation.php and use the code from model/VacationHandler (which is 
already used by users/vacation.php).

I had a look at the 2.3 code and added code to fix
    3148692 - Modifying a users vacation as admin is not logged
The changes were not too difficult, and should not cause any 
regressions.

If you want to test my changes, try SVN r987 from the 2.3 branch.

Be warned that 
    3148694 - Modifying a users vacation as user is DOUBLE logged
also applies to the code I added - I'd say that's better than no 
logging ;-)
See my comment in the bugreport for the technical details.


Regards,

Christian Boltz
-- 
Nein, es geht nicht um eine Sammlung von Pornobildern. Ich sag's
lieber gleich, weil die Leute immer breit grinsen, wenn ich von
"vielen winzigen Dateien" spreche. :-))) 
[Ratti in suse-linux über seine Fontsammlung]

Re: [Postfixadmin-devel] 2.3.3 release?

[Tanstaafl <tan...@li...>]

On 2011-03-06 4:22 PM, Rudi Floren wrote:
> No you can't. It wasn't compatible with 2.3 sry.
> But Christian is working on it right now.
> 
> He writes a 2.3 compatible bugfix.

You guys rock... :)

> greets Rudi
> Am 06.03.2011 22:19, schrieb Tanstaafl:
>> On 2011-03-06 2:19 PM, Rudi Floren wrote:
>>> look at rev. 981
>>> I think i have fixed the logging problem.
>> Well... I try to stick with my package manager, especially for mission
>> critical stuff.
>>
>> Where/what was the fix? Is it something I can apply by simply replacing
>> one or two files? I could do that... :)

Re: [Postfixadmin-devel] 2.3.3 release?

[Rudi F. <rud...@go...>]

No you can't. It wasn't compatible with 2.3 sry.
But Christian is working on it right now.

He writes a 2.3 compatible bugfix.

greets Rudi
Am 06.03.2011 22:19, schrieb Tanstaafl:
> On 2011-03-06 2:19 PM, Rudi Floren wrote:
>> look at rev. 981
>> I think i have fixed the logging problem.
> Well... I try to stick with my package manager, especially for mission
> critical stuff.
>
> Where/what was the fix? Is it something I can apply by simply replacing
> one or two files? I could do that... :)
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] 2.3.3 release?

[Tanstaafl <tan...@li...>]

On 2011-03-06 4:19 PM, Tanstaafl wrote:
> On 2011-03-06 2:19 PM, Rudi Floren wrote:
>> look at rev. 981
>> I think i have fixed the logging problem.
> 
> Well... I try to stick with my package manager, especially for mission
> critical stuff.
> 
> Where/what was the fix? Is it something I can apply by simply replacing
> one or two files? I could do that... :)

Oh... totally forgot to say... THANKS! for working on it! :)

Re: [Postfixadmin-devel] 2.3.3 release?

[Tanstaafl <tan...@li...>]

On 2011-03-06 2:19 PM, Rudi Floren wrote:
> look at rev. 981
> I think i have fixed the logging problem.

Well... I try to stick with my package manager, especially for mission
critical stuff.

Where/what was the fix? Is it something I can apply by simply replacing
one or two files? I could do that... :)

Re: [Postfixadmin-devel] PFA v3

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 6. März 2011 schrieb Rudi Floren:
> ohhh sry. I meant english^^

*g*

> First the structure of our svn project.
> Normally you add features in trunk. At a point where it runs without
> errors you start a new branch. You solve bugs in this branch an merge
> it into trunk. If you have a new bugfree Version you release a tag.
> The problem is that we have many branches for each version instead
> of branches for 2.1, 2.3 and  2.4.

> We have to fix our svn structure 

Yes, we have accidently tagged some releases into branches/ instead of 
tags/. Yes, we have to fix the svn structure.

Don't be surprised if you see lots of "svn mv" commit messages in the 
next hours or days...

> or use something mor modular like git.

Switching to git would cause some problems for us - for example 
upgrade.php depends on the SVN revision number to work. I'm sure there 
are ways how to do something similar in git (date?), but "never change a 
running system" applies here IMHO. We have other areas where investing 
time is more useful.

> Another point is the start of a 3.0 branch.
> The main goals are:
> *Split handlers in  model and controller

Can you give an example how such a split would look like?
I'm not too deep in the MVC theory, so this slightly sounds like 
buzzwords to me ;-)

> *extract db function into special db layer.

Define "layer", please.
Regarding OOP: As long as it makes things easier for us and/or for the 
users. See my answer to "About Trunk version" for the long version.

> *refactoring of function.inc.php. It should only have helper
> functions 

Agreed. A split by functionality (database, helper functions, ...) would 
be a good idea. The current functions.inc.php with 2500+ lines is only 
maintainable if you search for the function name...

For doing the actual split, we should "svn cp" functions.inc.php to a 
new name and then remove the lines that should no longer be in the 
respective file. This is slightly more work than just moving code to a 
new file, but has the advantage of not breaking svn history. (The svn 
history has helped me more than once to understand why some code was 
written the way it is.)

So the question is: Which parts should we split out and how should we 
name the file? I'd say:
- database specific functions (db_*)
- validation functions (like check_email)
- maybe: functions for the web interface (TODO: textarea_to_array)

I intentionally skipped the filename part because I have no better idea 
than db_functions.php for now ;-) - proposals?

> like array_remove etc.

Good example - with a TODO tag attached *g*

> *new path system for support the mvc concept as good as possible.

I'm open for proposals.

> *user defined fields in database and backend. (see: CCK in drupal 6)

I'd say "see fetchmail.php" (or model/DomainHandler for an unfinished 
class-based version of it). We just need to provide a hook so that the 
field array ($struct) can be modified from the config.

The only thing that can't be handled by changing the $struct array is 
using custom validation functions for a field - in this case a new class 
based on a model/* with the function added would be the way to go. (That 
would probably affect 1% of the "custom field" cases - most requests we 
got until now didn't require special validation.)

> *better setup, with automatic config.local.php creation

Sounds like a good idea - but also like lots of work...
If we do this, we should also support a versioned config so that it's 
possible to ask just for the new config options.

> *better support of PFA-CLI

Obviously. It's still unfinished.

> *upgrade from 2.2, 2.3 and 2.4 to 3.0

We already have that - see upgrade.php :-)  (included by setup.php)
IIRC it can even upgrade from 2.1...

> *some feature request in our tracker

Indeed, there are some good ideas in there.

I'd like to add another one:
* Invent days with more than 24 hours ;-))


Regarding "3.0 branch": I'm against it and the reason is simple: 
IMHO trunk is our "3.0 branch". We should finish all the things we have 
started there (CLI, model/*, use model/* from web interface, ...).
Creating a separate 3.0 branch would only lead to superfluous merge 
work.
When we do the 3.0 final release, we can/should of course create a 3.0.x 
branch that is handled similar to the 2.3 branch is now (only bugfixes).

As far as I can tell (I still use 2.3.x on my production servers) the 
current status of trunk is useable if you can accept some minor bugs. 
Compared to 2.3.x we already have some added features, even if some of 
them are incomplete.

Therefore I'd propose to do 2.9.x [1] releases (as in "beta" or "3.0 
preview") regularly to enable users to use the already finished parts, 
but with a clear note [2] that they have to expect small bugs and 
incomplete implementation of the new features.

We should also continue to maintain the 2.3 branch (only bugfixes, no 
new features) until we release 3.0 final for people that prefer 
stability over new features.


Regards,

Christian Boltz

[1] The reason for 2.9.x instead of "3.0 beta" is the easier handling of
    the version number in RPM (and probably DEB) because 2.9.x < 3.0,
    but "3.0 beta1" or "3.0 preview1" is hard to compare to "3.0".
    Even if we decide to use "3.0 previewX", I'll have to package it as 
    2.9.x to avoid update problems - so we should also use 2.9.x for the 
    tarballs ;-)

[2] AFAIK Sourceforge can display a README directly on the download page
-- 
> Als Vanilla werden die ungepatchten LinuxKernel bezeichnet die es
> z.B. bei http://www.kernel.org gibt.
Genau. Sozusagen ein Kernel ohne Aroma. Ich hatte den 2.4.19-pre7 
probiert, der schmeckt nur nach Kernel - und geht. 
[> Markus Kolb und Jörg Lippmann in suse-linux]

Re: [Postfixadmin-devel] 2.3.3 release?

[Rudi F. <rud...@go...>]

look at rev. 981
I think i have fixed the logging problem.

Am 06.03.2011 17:39, schrieb Tanstaafl:
> On 2011-03-04 6:14 PM, Christian Boltz wrote:
>> Am Donnerstag, 3. März 2011 schrieb Tanstaafl:
>>> On 2011-03-03 4:38 PM, Christian Boltz wrote:
>>>> Besides that, the diff (see [1]) looks good and we don't have
>>>> critical open bugs in the bugtracker.
>>> What about the broken logging bugs I reported? I'd really like to see
>>> them fixed...
>> I'd also prefer to have an empty bug list ;-) but if we wait with the 
>> release until we reach that status, you'll see PostfixAdmin 2.3.3 in two 
>> years - if nobody finds new bugs ;-)  (see sig *g*)
> I understand, but logging bugs, imo, should be given a higher priority,
> because without proper logging, finding *other* bugs is much harder or
> even impossible (especially for non programmers like myself)...
>
>> OTOH, what we have in the 2.3 branch now (see my changelog sniplet) 
>> includes one major and long-standing bugfix (multiple alias targets in 
>> create-alias) and several smaller fixes.
>>
>> I really want to have those fixes released. This doesn't mean I/we won't 
>> fix the bugs you reported, it just means that they won't make it in the 
>> 2.3.3 release.
> Understood, and can't complain if you decide to go ahead... ;)
>
>> That said: I won't have time to work on PostfixAdmin in the next days 
>> because the carnival season is in its end phase and I'm on tour with a 
>> big float in some carnival parades the next 4 days.
> Sounds like fun... so have some (fun, that is)! :)
>
>> If you send patches for one or more of your bugreports until ash 
>> wednesday that are not too intrusive (and don't look dangerous to me), 
>> I'll include them for 2.3.3.
> If I was a programmer, I'd be happy to, but alas...
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] 2.3.3 release?

[Tanstaafl <tan...@li...>]

On 2011-03-04 6:14 PM, Christian Boltz wrote:
> Am Donnerstag, 3. März 2011 schrieb Tanstaafl:
>> On 2011-03-03 4:38 PM, Christian Boltz wrote:
>>> Besides that, the diff (see [1]) looks good and we don't have
>>> critical open bugs in the bugtracker.

>> What about the broken logging bugs I reported? I'd really like to see
>> them fixed...

> I'd also prefer to have an empty bug list ;-) but if we wait with the 
> release until we reach that status, you'll see PostfixAdmin 2.3.3 in two 
> years - if nobody finds new bugs ;-)  (see sig *g*)

I understand, but logging bugs, imo, should be given a higher priority,
because without proper logging, finding *other* bugs is much harder or
even impossible (especially for non programmers like myself)...

> OTOH, what we have in the 2.3 branch now (see my changelog sniplet) 
> includes one major and long-standing bugfix (multiple alias targets in 
> create-alias) and several smaller fixes.
> 
> I really want to have those fixes released. This doesn't mean I/we won't 
> fix the bugs you reported, it just means that they won't make it in the 
> 2.3.3 release.

Understood, and can't complain if you decide to go ahead... ;)

> That said: I won't have time to work on PostfixAdmin in the next days 
> because the carnival season is in its end phase and I'm on tour with a 
> big float in some carnival parades the next 4 days.

Sounds like fun... so have some (fun, that is)! :)

> If you send patches for one or more of your bugreports until ash 
> wednesday that are not too intrusive (and don't look dangerous to me), 
> I'll include them for 2.3.3.

If I was a programmer, I'd be happy to, but alas...

Re: [Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

ohhh sry. I meant english^^


First the structure of our svn project.
Normally you add features in trunk. At a point where it runs without
errors you start a new branch. You solve bugs in this branch an merge it
into trunk. If you have a new bugfree Version you release a tag.
The problem is that we have many branches for each version instead of
branches for 2.1, 2.3 and  2.4.

We have to fix our svn structure or use something mor modular like git.


Another point is the start of a 3.0 branch.
The main goals are:
*Split handlers in  model and controller
*extract db function into special db layer.
*refactoring of function.inc.php. It should only have helper functions
like array_remove etc.
*new path system for support the mvc concept as good as possible.
*user defined fields in database and backend. (see: CCK in drupal 6)
*better setup, with automatic config.local.php creation
*better support of PFA-CLI
*upgrade from 2.2, 2.3 and 2.4 to 3.0
*some feature request in our tracker

What do you think?

Should we create a 3.0 branch?
greets Rudi




Am 06.03.2011 13:41, schrieb David Goodwin:
> Rudi Floren wrote :
>> [translation into german on request]
> Don't care about German, English would be kind of cool, given the
> subject...
>
> thanks
> David.
>
>
>> Hallo Christian,
>>
>> ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
>> die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
>> entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
>> Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
>> svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.
>>
>> Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
>> Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
>> context starten. Generell schon mal eine todo anfangen.
>> Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
>> (einige aus meinem privaten wunsch sammelsorium), wie
>> *trennung von Model und Controller
>> *trennung der db functionen aus der functions.php
>> *generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
>> *neues pfad system, um das mvc konzept bestmöglich auszunutzen.
>> *von usern eingepflegte spalten. (stichwort CCK in drupal)
>> *besseres setup, mit automatischer setup.php creation.
>> *upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
>> *verbesserte unterstützung von PFA-CLI
>> *etc.
>>
>> Was sagst du dazu?
>>
>> Würd mich über eine antwort freuen.
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] PFA v3

[David G. <da...@co...>]

Rudi Floren wrote :
> [translation into german on request]

Don't care about German, English would be kind of cool, given the
subject...

thanks
David.


> Hallo Christian,
> 
> ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
> die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
> entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
> Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
> svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.
> 
> Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
> Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
> context starten. Generell schon mal eine todo anfangen.
> Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
> (einige aus meinem privaten wunsch sammelsorium), wie
> *trennung von Model und Controller
> *trennung der db functionen aus der functions.php
> *generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
> *neues pfad system, um das mvc konzept bestmöglich auszunutzen.
> *von usern eingepflegte spalten. (stichwort CCK in drupal)
> *besseres setup, mit automatischer setup.php creation.
> *upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
> *verbesserte unterstützung von PFA-CLI
> *etc.
> 
> Was sagst du dazu?
> 
> Würd mich über eine antwort freuen.
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]