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