On 6 June 2013 14:41, Olemis Lang <[email protected]> wrote: > 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 ;) >
I think we all want to keep it fully functional, we just disagree what that functionality should be. If our current approach of a default product and redirections in order to not expose the product complexity to users when they first get set up causes too many issues, we should consider a different approach: Simply asking users to set up their first product when they first launch Bloodhound. Then everything is always in products from the start, without the default product weirdness. - Joe > -- > Regards, > > Olemis. > -- Joachim Dreimann | *User Experience Manager* WANdisco // *Non-Stop Data* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
