On 27. Jun, 2013, at 13:55, Antonia Horincar wrote:

> Thank you very much. It was a silly mistake on my part, however I
> don't understand why the template is being invoked when accessing the
> 'main' path and not 'api/ticket/1' and why do I still get the error
> when I access 'api/ticket/1'.

There are two factors in this: first is the environment name which is 'main' by
default. You can see this environment was created as part of the setup in the
'installer/bloodhound/environments' directory.
So in order to access any resources within a certain environment, you will need
to specify this in the URL. In most cases this means prefixing the path with
/main.

The second factor has to do with the multiproduct support in Bloodhound.
Since Trac doesn't support multiple projects/products within a single
environment, all resources are accessed in more or less the same manner - using
"global" URLs, e.g.:
  /main/ticket/10
  /main/wiki/Guide
  /main/admin/accounts/config
etc.

In Bloodhound however, most of the resources belong to a specific product and
cannot be global as it wouldn't make much sense. A specific ticket is always
considered to be bound to a certain product, and can only be accessed through
its product-scoped URL (there are some exceptions to this, but we'll ignore that
for now). So instead of the ticket URL above you should now get something like:
  /main/products/<pfx>/ticket/10
where <pfx> is the prefix of the product to which ticket belongs.
(If you navigate to the global dashboard (/main/dashboard), you will be able
to see all the products configured for the environment.)

Hope this helps,
matevz

> 
> On Thu, Jun 27, 2013 at 11:48 AM, Matevž Bradač <[email protected]> wrote:
>> 
>> On 26. Jun, 2013, at 23:57, Antonia Horincar wrote:
>> 
>>> On Wed, Jun 26, 2013 at 9:30 PM, Matevž Bradač <[email protected]> wrote:
>>>> 
>>>> On 26. Jun, 2013, at 20:12, Antonia Horincar wrote:
>>>> 
>>>>> I just noticed that in the guide[1], when reaching the step that
>>>>> requires the setting up of set$DBSTRING, it points to trac.db. I tried
>>>>> to install Bloodhound again (in another directory), and when it came
>>>>> to setting up set$DBSTRING, I put bloodhound.db instead of trac.db.
>>>>> After finishing the installation, I opened bloodhound.db in sqlite3
>>>>> and selected ticket 1. This time it worked and it returned:
>>>>> 1|defect|1372269942652842|1372269942652842|||major||antonia||||new||Porc|porc
>>>>> ||@
>>>>> 
>>>> 
>>>> For sqlite-based installations you probably don't need the
>>>> manual installation method, you can use the quick version[1]
>>>> and replace the step
>>>> pip install -r requirements.txt
>>>> with
>>>> pip install -r requirements-dev.txt
>>>> 
>>>> [1] https://issues.apache.org/bloodhound/wiki/BloodhoundInstall
>>>> 
>>>>> 
>>>>> However, I installed my plugin in this copy of Bloodhound as well and
>>>>> I still get the Invalid ticket number error.
>>>> 
>>>> Ok, since match_request() is being called, you can try to
>>>> retrieve the ticket from the database in that method first.
>>>> If that works, compare the self.env in match_request()
>>>> with the one in process_request() - they should match.
>>>> If it doesn't work, we'll probably need to see a bit more
>>>> code in order to make more assumptions. =)
>>> 
>>> I have retrieved the ticket in the match_request method and then
>>> compared the self.env with the one in process_request and they are the
>>> same.
>>> 
>>> I put the code here
>>> https://code.google.com/p/bloodhound-embeddable-objects-plugin/
>>> (it's the first time I'm using SVN, I'm not sure I did everything right).
>>> 
>> 
>> Thanks for the code, found the error.
>> The problem is that your template (ticket.html) is named the same as Trac's,
>> and when the bhtheme plugin starts rendering, it picks that one over yours.
>> This is then replaced in bhtheme with the Bloodhound version 
>> (bh_ticket.html),
>> that has certain expectations on which ticket-related data should be present 
>> in
>> order to render the ticket (e.g. author_id, attachments etc.)
>> 
>> AFAIK the best method to remedy this would be to rename your template to
>> something unique in order to be processed by the engine. Something like
>> bh_emb_ticket.html or similar should do the trick (the same name should
>> also be returned in the plugin's process_request() implementation).
>> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> [1] 
>>>>> https://issues.apache.org/bloodhound/wiki/BloodhoundDetailedInstallation
>>>>> 
>>>>> On Wed, Jun 26, 2013 at 8:38 PM, Antonia Horincar
>>>>> <[email protected]> wrote:
>>>>>> Yes, I am. This is my entire match_request method:
>>>>>> 
>>>>>> def match_request(self, req):
>>>>>>    match = re.match(r'/api/ticket/([0-9]+)$', req.path_info)
>>>>>>    if match:
>>>>>>          req.args['id'] = match.group(1)
>>>>>>          return True
>>>>>> 
>>>>>> I think the problem is in the database, I might not have set it up
>>>>>> properly. When I make queries in the database, I get a 'no such table:
>>>>>> <table>" error. But I installed everything by following this guide:
>>>>>> https://issues.apache.org/bloodhound/wiki/BloodhoundDetailedInstallation
>>>>>> I am really confused now, I can't see why the database has no tables in 
>>>>>> it.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Jun 26, 2013 at 7:50 PM, Anze Staric <[email protected]> 
>>>>>> wrote:
>>>>>>> This looks ok. Are you returning True in your match_request if request 
>>>>>>> matches?
>>>>>>> 
>>>>>>> On Wed, Jun 26, 2013 at 5:44 PM, Antonia Horincar
>>>>>>> <[email protected]> wrote:
>>>>>>>> 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
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>> 
>> 

Reply via email to