API: stream parameter not handled correctly

According to documentation, the stream parameter of the API call
entry_add_comment should be a stream of a sender of a comment [1]. However,
if that kind of stream parameter is used
(stream/commentator@jaiku.com/comments), the produced comment is linked
into non-existing entry. It is possible to use also the stream owned by an
original author of a commented entry (stream/entryowner@jaiku/comments).
That way the link will be correct, but unfortunately this hack is not
working with entries in channels.

What steps will reproduce the problem?

* Case 1: Invalid linking

1. Send the following API call:
method=entry_add_comment&nick=YOURNICK%40jaiku.com&stream=stream%2F<your_nick>%4
0jaiku.com%2Fcomments&entry=stream%2F<owner>%40jaiku.com%2Fpresence%2F<item_uid>
&content=<comment>

2. Go to Your Jaikus page and click to the link to the original Jaiku in
the comment you have just created.

3. The page does not exist!

* Case 2: Hack that does not work in channels

1. Send the following API call:
method=entry_add_comment&nick=YOURNICK%40jaiku.com&stream=stream%2F<owner>%40jai
ku.com%2Fcomments&entry=stream%2F<owner>%40jaiku.com%2Fpresence%2F<item_uid>&con
tent=<comment>

2. Go to Your Jaikus page and click to the link to the original Jaiku in
the comment you have just created.

3. Now it works, but you cannot use this method in channels.

[1] From svn/trunk/common/api.py (r1):

def entry_add_comment(api_user, _task_ref=None, **kw):
  """ Add a comment to given entry
...
    * stream - the stream in which the entry this comment is on resides
...
     'rv': {'comment': {'stream': 'stream/test@example.com/comments',
                        'uuid': '1234567890abcdef',
                        'entry': 'stream/root@example.com/presence/12345',
                        'owner': 'root@example.com',
                        'actor': 'test@example.com',
Original issue reported on code.google.com by henrik.h...@oulu.fi on 16 Mar 2009 at 6:28
loreanabelle / jaikuengine

API: stream parameter not handled correctly #48
