Page "Proposals/BEP-0003" was changed by olemis Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=8> Revision 8 Comment: [BEP-0003] Product-specific settings (refs #115) and corollaries mentioned by jure in [/wiki/Proposals/BEP-0003?version=5 version 5] Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0003 ========================================================================= --- Proposals/BEP-0003 (version: 7) +++ Proposals/BEP-0003 (version: 8) @@ -36,7 +36,7 @@ The key design mechanism is known as ''product environments'' . Their main goal is to provide components (both in core and those defined by plugins) with a lightweight virtual representation of an isolated environment inside the ''global'' environment when dealing with requests addressed to a resource owned by a product. The following figure illustrates how they work. -[[Image(Product_environments.png)]] +[[Image(Product_envs_small.png)]] If you notice similarities with the [attachment:wiki:Proposals/BEP-0003/MultienvParentDir:Multienv_small.png reference multi-environment setup] it is an intentional design decision. @@ -82,12 +82,12 @@ None }}} -''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component` APIs by inheriting most of the properties of the global `trac.env.Environment`, so they will act as wrappers. As a consequence instances will have its own components cache, which means that every active component class will only have a single instance for every product environment. +''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component` APIs. As a consequence instances will have its own components cache, which means that every active component class will only have a single instance for every product environment. They will inherit most of the properties of the global `trac.env.Environment` by acting as wrappers often forwarding method calls to be handled by the parent global environment. The following list explains how product environments will adapt existing environment API while still being compatible with it. - - '''[=#product-env-conf] conf''' will contain an - instance of `trac.conf.Configuration` (or equivalent) setup in + - '''[=#product-env-config] config''' will contain an + instance of `trac.config.Configuration` (or equivalent) setup in such a way that it reads product-specific settings from a file located at path `./conf/product_<product prefix>.ini` relative @@ -108,17 +108,94 @@ The following is a list of proposed features for multi product support in ''Bloodhound''. Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility] below. In each case you'll find notes explaining how candidate implementation will solve related issues. -=== Per product ticket workflow #workflow +=== Product components ecosystem #components + +All the functionalities installed in the global environment (e.g. blogs, pastebins) should be available for products as well. Nonetheless they should be enabled/disabled on a per product basis. + +{{{ +#!div class="well" +{{{ +#!span class="label label-info" + +Implementation notes +}}} +Product environments are meant to implement `trac.core.ComponentManager` API and inherit global plugins installations by design. Hence every component class will have a singleton instance for each product (besides the one for the global environment). Components are enabled/disabled via `[components]` section in configuration file. The fact that each product will have a [#config separate configuration file] also means that there will be one such section to enable/disable each one on a per product basis. + +This situation is quite similar to what happens nowadays in multi-environment installations. + +}}} + +=== Product-specific settings #config + +Component settings should be configurable per product. For practical reasons if there is no explicit option assignment set for a particular product then it should inherit option value set for the global environment. + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} +Product-specific settings will be implemented in #115 . + +`trac.conf.Configuration` instance in [#product-env-config config attribute] of product environments will read settings from `product-<product prefix>.ini` file and will be configured to inherit settings in environments' `trac.ini` file. + +Even if the proposal only suggests ''ini files'' to store product-specific configuration it is also possible to think of using other configuration repositories (e.g. database, [http://hadoop.apache.org/hdfs/ HDFS], remote data repositories). It is a feasible enhancement though details have been omitted. +}}} + +The following requirements are a corollary , considering that such customizations are performed in the configuration file. + +==== Per product ticket workflow #workflow Depending on the product, different ticket workflows should be supported. -=== Per product notifications +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} +Edit `[ticket-workflow]` section in `product-<product prefix>.ini` file. + +[TracWorkflow#AdvancedTicketWorkflowCustomization Advanced ticket workflow customization] will be possible for individual products since [#components components may be enabled/disabled on a per product basis]. + +}}} + +==== Per product notifications #notification Notifications should be configurable per product. -=== Per product ticket field configuration +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} +Edit `[notification]` section in `product-<product prefix>.ini` file. + +}}} + +==== Per product ticket field configuration Components, milestone, version, priority, defaults, custom fields should be configurable per product. + + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} +Edit `[ticket-custom]` section in `product-<product prefix>.ini` file. + +}}} === Per product permission scheme #permissions @@ -165,6 +242,8 @@ == Rejected ideas #rejected Many interesting ideas have been proposed but not all could make their way into final specification because of conceptual, practical or other reasons. Below you'll find the most relevant instances together with brief comments explaining the decision , and maybe links to relevant messages in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing list archive] . + + '''TODO''' : nothing rejected so far. == Backwards Compatibility #backwards-compatibility -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
