On 30. Jun, 2013, at 6:52, Olemis Lang wrote: > On 6/29/13, Antonia Horincar <[email protected]> wrote: >> Hi, >> > > :) > >> Thank you for your help. But unfortunately I'm still struggling with the >> problem. >> I noticed that when printing the self.env variable in the match_request >> method from my API I get: >> <multiproduct.env.Environment object at 0x1bd1610> >> but when I print the self.env variable from the match_request from the >> TicketModule class in trac.ticket.web_ui, I get this: >> <ProductEnvironment u'@' at 0x7f0ce07d0d90> >> >> I have spent a lot of time trying to understand why is my API using another >> environment, but I couldn't. Do you have any idea why this is happening? >> >> Thanks >>
Hi, Which URL were you using when accessing your API? If it was the /main/api/ticket/<ID> then you would get the multiproduct.env.Environment in self.env. If accessed from /main/products/<prefix>/api/ticket/<ID> however, it should be the ProductEnvironment. As Olemis mentions below, the multiproduct.hooks module is responsible for dealing with product-related handling and redirects, namely: a) if a product is referenced through e.g. /main/products/<prefix>... then the product-specific environment is instantiated and the request passed to it b) if it's not a product-related request in question, then the code checks whether the request should be passed to the default product. This is because certain requests don't make sense in the global scope (e.g. /newticket, /milestone etc.). If none of the above conditions apply then the request is handled in the global context, which I'm assuming happened in your case. -- matevz > > Maybe that's caused by *default* hooks redirecting requests to default > product . See multiproduct.hooks module in Bloodhound Multiproduct > plugin for further details . > > -- > Regards, > > Olemis.
