On 6 June 2013 08:49, Matevž Bradač <[email protected]> wrote: > > On 5. Jun, 2013, at 22:58, Olemis Lang wrote: > > > On 6/5/13, Matevž Bradač <[email protected]> wrote: > >> > >> On 5. Jun, 2013, at 21:17, Olemis Lang wrote: > >> > >>> Message subject is self-explanatory . Is it possible to create tickets > >>> in the global environment ? How ? > >> > >> No. > >> The global environment acts as a placeholder for all things global, > >> e.g. actual products, users, repositories etc. Tickets, as well as > >> components, versions etc. are all related to an actual product, it > >> would serve no purpose to attach them to a global environment. > >> > > > > 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. When a parent has the same properties as a sibling we're introducing new conceptual complexities. That makes for great family intrigue novels, but not good interaction design. Why do you want to create tickets (and at that point milestones, versions, components) in the global environment anyway? I can only come up with cases that could just as well be served by gathering them in a product. Cheers, Joe > > > > > Anyway , in this case I asked because this breaks some assumptions > > made by the functional test suite . > > Ok. > > > > >>> > >>> AFAICS now REDIRECT_DEFAULT_RE in hooks.py will force some requests > >>> sent to global env URL namespace to be processed in the context of > >>> default product env . Therefore it seems to me that this is expected > >>> behavior . Why ? > >> > >> To "ease" the transition to multiproduct so to speak. Certain operations > >> (such as creating a ticket) do not make sense in a global environment, > > > > IMO (at least sometimes) they do. Anyway I'll have to deal with this > > in functional testing code. > > That would be best - since the global environment's name is an empty > string, > there may be assumptions made in the code which will not handle the global > environment in the same manner. > > > > >> so they are redirected to a default product instead. > > > > understood > > > >> Another option would be to hide/disable those operations in a global > >> view, but I gather that wouldn't be such a simple task (UI overhaul, > >> lots of messing around with templates etc.) > >> > > > > Please do not do that . In some deployments I'll use the global > > environment as usual , with tickets, wikis, ... everything . > > Oh I didn't mean this will actually be the case, just that it could've > been implemented in that manner. (I would vote against that as well) > > > > > -- > > Regards, > > > > Olemis. > > -- Joachim Dreimann | *User Experience Manager* WANdisco // *Non-Stop Data* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
