Beside some minor information leakage I don't see a reason why we 
shouldn't use it. I used UID originally because that's what we have to 
do with iTip.

Changed for Kronolith 2.2.

Ping, last chance to change/fix this for 2.2...

So I think I've been a bit dense here. Can't we solve this problem 
definitively by passing the calendar_id and event_id into attend.php 
instead of the uid? Jan, any reason not to do that (link length 
perhaps, but given these issues, I think specificity is worth it).

Yes, please do create another ticket with as much detail as possible. Thanks.

Ok, I think I got it. So some conclusions so far:



- In attend.php there is no way to know the organizer, because we are 
not talking about iCal. We only know an UID given as GET parameter.



- Anyway, I think that organizer information from an imported iCal is 
lost because function Driver.php: fromiCalendar doesn't parse 
ORGANIZER attribute, so even if you would know the organizer 
information at attend.php, it is impossible retrieving  the correct 
event from backend, because at least in sql, that information doesn't 
exists (only creator_id, but as you said, organizer an creator_id are 
different concepts ).



- To solve the problem of retrieving the correct event at attend.php, 
I think we should keep our attention at the creator_id. The scenario 
described (I mean, when you get tree links pointing to attend.php to 
accept, accept tentatively or decline) happens always because the 
event was created in Kronolith, and the event (if not deleted) MUST 
exists in backend, with a creator_id). So maybe the solution should be 
adding that information in that links (with another GET parameter 
called creator=ID).



- Finally, I think that the issue described before about the tracking 
of creator_id done by import and put api methods should be fixed 
(maybe I should create another ticket), specially if the previous 
solution proposed is done.





- About the creator_id in import/put api methods a still thinking that 
is an issue that should be fixed, but i understand that, because

creator_id is who saved the event into Kronolith. That's not always 
going to be the organizer.

When I say that i don't know what do you mean with organizer signify 
that, when you say "check the organizer instead", i don't know how do 
you do that. For me, tracking the organizer means check creator_id 
field to know who is the event organizer. How else?

That is the reason because i think that respect creator_id information 
is critical to know who organized the event... And that is the reason 
because i did the comment about import/put. That methods are very 
similar, but import respects creator_id info (see <a 
href="http://bugs.horde.org/ticket/6606#c2">Comment 2</a>) and put 
doesn't.



Hope I could explain me better.

See ticket 3965 re: organizer. I don't understand your comment about 
import vs. put.

Then, i don't know what do you mean with "organizer".

In iCalendar format exists an attribute called ORGANIZER, but never is 
parsed, at least by Driver.php: fromiCalendar() function. And also, 
there is no database attribute in kronolith_events for organizer, only 
"creator_id". In Comment #2 you talk about check the organizer... how 
then?



Apart from that, i don't understand why makes sense don't change 
creator/owner at api.php:_kronolith_put and it doesn't at 
api.php:_kronolith_import

Actually we want to track the organizer separately from the creator - 
the creatorId is a Horde username, which might not be true for the 
organizer of an invitation.

That was my first try, and that solution consists in 3 steps:



- Retrieve an event with that UID, it doesn't mind which one

- Extract the CreatorID, to know the user who created the event.

- Get the creatorid's calendars and check, one by one, which one has 
the event with that UID



That solution, apart from more complicated, has a problem with IMP 
(and that is, maybe, another bug): when you accept an invitation with 
IMP and you select "Add to my calendar" option, it doesn't respect the 
creatorid!!!. Lightning does, but not IMP. That is because Lightning 
uses api method contact/put (webdav) and IMP uses contact/import. 
Contact/put has (api.php:512,513):



                     // Don't change creator/owner.

                     $event->setCreatorId($existing_event->getCreatorId());



contact/import hasn't got that instruction.



So, to summarize, i think that checking organizer could be valid only 
if we ensure that creatorid is preserved everytime.

How about checking the organizer instead?

The problem appears when a user tries to accept an event using the link

provided. attend.php, the script which updates the status, uses (line 46):



  $event = $kronolith_driver->getByUID($uid);



getByUID returns the first copy of an event (remember that no session

has been started), but maybe, on BD exists other copies of the event,

some of them without attendees. In that case, kronolith returns a "You

are not an attendee of the specified event." message.



I have solved the problem like this:



-  $event = $kronolith_driver->getByUID($uid);

+  $events = $kronolith_driver->getByUID($uid,true);

+  foreach ($events as $e){

+     if ($e->hasAttendee($user)){

+        $event=$e;

+     }

+  }



In that solution, i allways suppose that only one event has the 
correct attendee info (copies souldn't), so i examine every copy 
returned by getByUID.



I did not make a path for that because i don't know if my solution is 
the best one.