incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Mon, 25 Feb 2013 17:23:25 GMT
On 2/25/13, Andrej Golcov <andrej@digiverse.si> wrote:
>>>> My understanding was, based on the mailing list discussions, that we
>>>> don't want tickets in global scope. That is why current implementation
>>>> creates the 'default' product and migrates the tickets. I think that
>>>> the 'Just Work' part is more of the UI/UX issue. I think that each
>>>> ticket should be linked to a product, it's up to the UI to make it
>>>> easy for the user to use environments with only one product (default
>>>> one). I find tickets in global scope confusing as it's not exactly
>>>> clear what they relate to.
>>>>
>>>> I would advocate global wikis for example, as it makes more sense.
>>>
>>> It's not global scope, it's default product scope which happens to have
>>> no name and no prefix and no value in the related database column.
>
> Let's look at this issue from UI point of view. AFAIR, we want to have
> consistent URLs and wiki links with product prefix for all products
> including default product
> e.g.http://host/env/default_product_name_here/ticket/1 and not
> http://host/env/ticket/1 when product prefix is None

Once again this is not accurate . Product URL mappings will be

http://host/env/products/<prefix>/ticket/1

... notice 'products' path prefix

URLs for global env will be just like they are now

http://host/env/ticket/1

> That means that default product must have some kind of prefix assigned
> even if it has product prefix set to NULL in DB.
>

As you can see , no . Besides global admin section and everything else
will still be needed .

> I think that the easiest way to solve this is setting default product
> prefix to some value during migration and not allowing Nulls for
> prefixes.
> Taking in mind that product prefix cannot be changed, I suggest to
> make default product prefix configurable during migration procedure,
> for example in ini file.
>

fwiw -1

-- 
Regards,

Olemis.

Mime
View raw message