It does get called, I wrote ticket_id = req.args.get('id') in the
process_request method and then printed ticket_id. After starting the
server, I looked in the logs and the correct id was there. I also
printed req.path_info and the output was /api/ticket/1.On Wed, Jun 26, 2013 at 6:34 PM, Anze Staric <[email protected]> wrote: > Can you try setting a breakpoint in the match_request method and see > what is happening? (Does it get called? What is the value of > req.path_info?) I don't see any reason why would requests be matched > in global environment, but not in product ones. > > On Wed, Jun 26, 2013 at 5:21 PM, Antonia Horincar > <[email protected]> wrote: >> On Wed, Jun 26, 2013 at 6:00 PM, Matevž Bradač <[email protected]> wrote: >>> >>> On 26. Jun, 2013, at 16:43, Antonia Horincar wrote: >>> >>>> On Wed, Jun 26, 2013 at 5:29 PM, Matevž Bradač <[email protected]> wrote: >>>>> >>>>> On 26. Jun, 2013, at 16:14, Antonia Horincar wrote: >>>>> >>>>>> Hi Pranay, >>>>>> >>>>>> Thanks for the link, I had a look at it yesterday, but unfortunately >>>>>> it doesn't help me with the error. >>>>>> >>>>>> I'm still not sure what's causing this error to come up every time I >>>>>> try to access a ticket through my API. The ticket exists, I checked >>>>>> this in the Python interpreter. I am suspecting that the problem might >>>>>> be caused by the environment, but don't know why or how to solve it. I >>>>>> have 'forced' the API to use the "bloodhound/environments/main" >>>>>> environment by writing >>>>>> env = trac.env.Environment("bloodhound/environments/main") >>>>>> in the process_request method (I only did this so that maybe I could >>>>>> see what's causing the error). >>>>>> After doing this, I tried to access the ticket again and the error was >>>>>> KeyError: 'author_id', and this made me think that maybe the >>>>>> application runs on a different environment that the one I forced my >>>>>> API to run on. I'm definitely not sure if this is the problem. I will >>>>>> continue to try to solve this, but I am stuck for now. If anyone has >>>>>> the slightest idea on what could be the problem, that would be more >>>>>> than welcome. >>>>> >>>>> This could be related to multiproduct functionality. Could you >>>>> specify some more details on the following: >>>>> - How was the ticket created? Programatically or in the web UI? >>>> >>>> The ticket was created through the web UI. >>> >>> Ok, it should "belong" to a specific product then. Do you have >>> multiple products set up, or are you just using the default one? >> >> I am using the default one. >> >>> >>>> >>>>> - What does the SQL dump for that ticket from the Bloodhound DB look >>>>> like? (e.g. something like "SELECT * FROM ticket WHERE id=1;") >>>> >>>> I looked at the logs in the console but the database queries are not >>>> displayed. Only the requests. >>> >>> Correct, you have to manually run the query from the database. >>> If you have installed Bloodhound with sqlite3 as its database, try >>> the following (you need to have sqlite3 installed beforehand): >>> 1. Traverse to the "db" directory in the BH environment. IIRC the >>> relative path should be "bloodhound/environments/main/db". >>> 2. Open the database with >>> sqlite3 bloodhound.db >>> 3. List the ticket using the select statement >>> SELECT * FROM ticket WHERE id=<ID>; >>> replace the <ID> part with the actual ticket ID. >> >> This is weird, it says Error: no such table: ticket. Did I not >> configure the database properly then? >> >>> >>>> >>>>> - How are you accessing that ticket from the code? I understand it's >>>>> from a template, is that template loaded in a specific product >>>>> environment or in the global one? >>>> >>>> The template is loaded only for my plugin, it's not a global one. Well >>>> actually, it doesn't load because from what I saw the error occurs >>>> before reaching the template. >>> >>> I'm assuming that the "self.env" referenced in your code doesn't >>> match the ticket's, or something similar. Could you dump the >>> self.env and ticket_id from the code, so that we can compare them >>> to the SQL dump? >>> >>>> >>>>> >>>>> -- >>>>> matevz >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Antonia >>>>>> >>>>>> On Wed, Jun 26, 2013 at 1:29 AM, Pranay B. Sodre >>>>>> <[email protected]> wrote: >>>>>>> Antonia- I am trying to understand this Ticket field myself. The place >>>>>>> I am >>>>>>> looking at to fully understand how this is structured is listed below. >>>>>>> The >>>>>>> structure is based on code written here >>>>>>> http://trac.edgewall.org/browser/branches/1.0-stable/trac/ticket/model.py?rev=11830 >>>>>>> >>>>>>> Look at line 120. I am not sure if this will answer your question, but >>>>>>> it a >>>>>>> place to look. >>>>>>> >>>>>>> Pranay B. >>>>>>> >>>>>>> "He is richest who is content with the least, for content is the wealth >>>>>>> of >>>>>>> nature."- >>>>>>> >>>>>>> Socrates >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 25 June 2013 14:31, Antonia Horincar <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I made a basic template for displaying ticket information when >>>>>>>> accessing a certain path, but I am having trouble with processing the >>>>>>>> ticket. It gives me an error "Ticket <id> does not exist" even though >>>>>>>> there is a ticket with the id that I entered. What I did in my api, >>>>>>>> after matching the request, in the process_request method was >>>>>>>> something like this: >>>>>>>> data = {'ticket': model.Ticket(self.env, ticket_id)}, where ticket_id >>>>>>>> is the id of the req argument. >>>>>>>> >>>>>>>> I have checked if the matching does indeed find the correct id, and it >>>>>>>> does. I have looked through the other Bloodhound APIs but I found no >>>>>>>> clue that could help me determine the cause of my error. If anyone >>>>>>>> encountered this error before and knows what might be causing it, can >>>>>>>> you please help me? I might be missing something or I might have >>>>>>>> misunderstood some concepts. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Antonia >>>>>>>> >>>>> >>>
