On 6/6/13, Gary Martin <[email protected]> wrote: > On 06/06/13 10:40, Joachim Dreimann wrote: >> On 6 June 2013 08:49, Matevž Bradač <[email protected]> wrote: >>> On 5. Jun, 2013, at 22:58, Olemis Lang wrote: [...] >>>> The global environment is yet another environment . Tickets et al. are >>>> resources related to an environment , so I do not see a reason to not >>>> to attach them to global env . >>> It's true that it's another environment, but AFAIK it's treated a bit >>> differently from product environments in the code, so you may run into >>> issues. >>> >> I believe that 'global' _should_ be treated differently too. From a >> user's >> perspective all products are siblings, global is a parent. [...] > > I can see why there would be a desire to use global to contain tickets > but if we do not allow it, there doesn't appear to be a huge hardship in > forcing the users to create a product dedicated to the reason that they > wanted to. > > The most common reasons for this might be to allow for users to raise > tickets associated with maintenance of the site itself but there is no > particular reason why this would be better than adding an 'infra' > product for instance. We do already allow for the global wiki to be used > as a base site wiki though we might even ask if there are more > appropriate ways of achieving this. >
kind of ... in my deployments I'll need a *meta* environment and global seems to be a good target . > There might be questions of what to do about single product environments > as users may wonder at the point of a container in this situation. IMHO , default should be ok in this case . > Overall though, I'm leaning towards no tickets in global so that > effectively it is not even considered a product - it is just a container > with some shared resources. > ... in any case I'll rethink everything for a while to see whether something like the infra product will be suitable . > Olemis - for what you want, do we need a means to fake a product where > the global product would be or something like that? What exactly is the > use-case? Can it effectively be achieved through webserver configuration? > One of the reasons is that (powered by custom bootstrap handlers) product's base URL is at subdomain.domain.tld whereas gobal's is at domain.tld so redirections to default product are problematic . Not the only issue I notice though . OTOH , when it comes to translating the functional test suite redirections make things a bit harder because there's a need to keep track of global vs default product context . That's beyond all other things that have changed in the UI and have an impact on functional testers as well <= /me working on fixing all this , and that's why I asked this question in first place Anyway , please let's keep global env fully functional ;) -- Regards, Olemis.
