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
|
