Re: [Apache Bloodhound] #115: Product-specific settings

[Apache Bloodhound <bl...@incubator.apache.org>]

#115: Product-specific settings
-------------------------+-------------------------------------------------
  Reporter:  olemis      |      Owner:  nobody
      Type:              |     Status:  new
  enhancement            |  Milestone:
  Priority:  major       |    Version:
 Component:              |   Keywords:  multiproduct environment
  multiproduct           |  configuration database
Resolution:              |
-------------------------+-------------------------------------------------

Old description:

> 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)
>   - Product-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])
>   - Product-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 product 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/product-<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.

New description:

 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)
   - Product-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])
   - Product-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 product 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/product-<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 :

 {{{
 #!py

 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.

--

Comment (by olemis):

 Oops !
 Highlighting python source code ... this time ...

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/115#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker