On 2/25/13, Andrej Golcov <[email protected]> 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.
