incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <>
Subject [Apache Bloodhound] #115: Product-specific settings
Date Mon, 25 Jun 2012 05:30:24 GMT
#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
 [ 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`
   - Project-specific fine grained permissions (i.e.
   - Different sources and hosts for growl notifications (i.e. `growl`
     used by [ GrowlPlugin])
   - Project-specific header and logo (i.e. `header_logo` section)
   - Different ways to collect statistics on groups of tickets for display
     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 :


 class ProductSettings(ModelBase):
     """Product settings table"""
     _meta = {'table_name':'bloodhound_product_settings',
             'key_fields':['product', 'section', 'option'],
             'no_change_fields':['product', 'section', 'option'],


 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 `` 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: <>
Apache Bloodhound <>
The Apache Bloodhound (incubating) issue tracker

View raw message