On 2/16/15, Branko Čibej <brane@wandisco.com> wrote:
> On 16.02.2015 16:25, Olemis Lang wrote:
>
[...]
>>> The options I can think of are:
>>>
>>> 1. Change the setup so that we are using the default product to serve
>>> all
>>> the pages.
>>> 2. Create a new StartWiki page to allow the users to select the product
>>> they want to work with.
>>>
>> Considering the answers to questions above I might have another
>> proposal ... which is basically to continue hosting the default
>> product at i.a.o/bh other potential new products at
>> i.a.o/bh/products/PREFIX and global admin at some other
>> non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
>> naming convention be chosen as well)
>
>
> I'd really hate having BH tickets etc. in the default product.
JFTR , the default product is just like any other regular product .
Indeed you can run a BH instance and never care about default product
at all .
OTOH by reviewing the code I found this .
{{{#!py
default_product_prefix = Option(
'multiproduct',
'default_product_prefix',
default='@',
doc="""Prefix used for default product when migrating single-product
installations to multi-product.""", doc_domain='multiproduct')
}}}
@John , this makes me think that legacy resources should be imported
into BH product if the following option is set in trac.ini prior to DB
upgrade .
{{{#!ini
[multiproduct]
default_product_prefix = BH
}}}
N.B There is a similar option [ticket] default_product , but it is not
related to the install procedure . Besides I think I should clarify
that the *global* environment is indeed different to any other product
e.g. it supports plugin install , global site admin ...
> They
> should be in the BH/bloodhound product.
I agree . In my previous message I was only talking about
"URL-to-environment mapping" .
> To maintain URL compatibility,
> we can design rewrite rules for the Apache config that make all
> product-scoped tickets, pages, etc. visible at their old locations.
>
HTTP 301 , isn't it ?
> The reason why it makes sense to scope all BH stuff into its own product
> is that it will then be easier for other projects to adopt BH as their
> issue tracker.
+1
p.s. Now that I take a look it seems that BH=0.4 does not have some MP
changes in product tables at all . I was wrong in my previous message
, sorry .
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
|