#115: Product-specific settings
-------------------------------------------------+-------------------------
Reporter: olemis | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: multiproduct | Version:
Keywords: multiproduct environment |
configuration database |
-------------------------------------------------+-------------------------
IMO one of the goals of multiproduct plugin should be to behave like (i.e.
not an exact clone though still similar to) an implementation of former
multi-environment setup e.g. via `TRAC_ENV_PARENT_DIR` but inside a single
environment . Hence each product should have its own configuration
settings . For practical reasons maybe it's a good decision to merge
product-specific options with environment's global options. The former
should override the later in a way similar to
[http://trac.edgewall.org/wiki/TracIni#GlobalConfiguration global
configuration] (i.e. `inherit.file` config option) .
Some use cases are :
- Notifications for different products sent to separate mailing lists
(i.e. `notification` section)
- Different default values for ticket fields (i.e. `ticket.default_*`)
- Different workflows for each product
- Product svn repostiory having particular branch and tags (i.e. `svn`
section)
- Project-specific fine grained permissions (i.e.
`authz_policy.authz_file`)
- Different sources and hosts for growl notifications (i.e. `growl`
section
used by [http://trac-hacks.org/wiki/GrowlPlugin GrowlPlugin])
- Project-specific header and logo (i.e. `header_logo` section)
- Different ways to collect statistics on groups of tickets for display
in
the milestone views (i.e. `milestone` section)
==== Implementation notes ====
Firstly it'd be nice to store project specific configuration in the
database (though it is possible to reuse existing implementation and load
values from plain-old files e.g.
''/path/to/env/config/project-<prefix>.ini'' ... <= this approach is cheap
enough to be taken into account ''';)''' . Table structure for this should
be pretty straightforward and simple . My initial suggestion is :
{{{
#!python
class ProductSettings(ModelBase):
"""Product settings table"""
_meta = {'table_name':'bloodhound_product_settings',
'object_name':'ProductSettings',
'key_fields':['product', 'section', 'option'],
'non_key_fields':['value'],
'no_change_fields':['product', 'section', 'option'],
'unique_fields':[],
}
}}}
All this should happen transparently , so that e.g. plugins source code
will work under these circumstances without requiring any change . In
order to get this done I suggest to inject (at a given time TBD during
request dispatching , filtering , handling , ... ) a replacement (i.e.
proxy object) of Trac environment wrapping the real environment but
returning product-specific configuration object for its `config` field .
Therefore a class implementing `ConfigParser` ''API'' on top of this
database structure is also needed .
Some side-effects may lead to changing current multiproduct implementation
. For instance, product name and description may be stored/retrieved by
referring to product-specific `project.name` and `project.descr` options
respectively , and that will work transparently due to the underlying
magic of `trac.config.Option` descriptor and its subclasses.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/115>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
