Problem with attend.php and getByUID()

The problem appears when a user tries to accept an event usi

Mon, 14 Apr 2008 15:46:18 +0000

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.

How about checking the organizer instead?

Thu, 24 Apr 2008 03:38:00 +0000

How about checking the organizer instead?

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

Mon, 28 Apr 2008 10:56:10 +0000

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.

Actually we want to track the organizer separately from the

Mon, 28 Apr 2008 20:15:17 +0000

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.

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

Tue, 29 Apr 2008 07:07:01 +0000

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

See ticket 3965 re: organizer. I don't understand your comme

Tue, 29 Apr 2008 18:31:50 +0000

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

When I say that i don't know what do you mean with organizer

Wed, 30 Apr 2008 12:23:10 +0000

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 Comment 2) and put doesn't. Hope I could explain me better.

creator_id is who saved the event into Kronolith. That's not

Wed, 30 Apr 2008 22:25:55 +0000

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

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

Thu, 01 May 2008 08:53:12 +0000

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

> - Finally, I think that the issue described before about t

Fri, 02 May 2008 04:02:10 +0000

> - 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. Yes, please do create another ticket with as much detail as possible. Thanks.

So I think I've been a bit dense here. Can't we solve this p

Fri, 02 May 2008 04:04:39 +0000

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).

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

Fri, 23 May 2008 19:12:45 +0000

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

Beside some minor information leakage I don't see a reason w

Sat, 24 May 2008 17:42:26 +0000

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.