| Summary | Problem with attend.php and getByUID() |
| Queue | Kronolith |
| Queue Version | HEAD |
| Type | Bug |
| State | Assigned |
| Priority | 1. Low |
| Owners | Jan Schneider <jan (at) horde (dot) org> |
| Requester | almarin (at) um (dot) es |
| Created | 04/14/2008 (27 days ago) |
| Due | |
| Updated | 05/02/2008 (9 days ago) |
| Assigned | 05/02/2008 (9 days ago) |
| Resolved | |
| Attachments | |
| Milestone | |
| Patch |
State ⇒ Assigned
Assigned to Jan Schneider
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).> - 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.
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
#2you 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.
State ⇒ Feedback
How about checking the organizer instead?Patch ⇒
Milestone ⇒
Queue ⇒ Kronolith
Summary ⇒ Probl
Type ⇒ Bug
Priority ⇒ 1. Low
State ⇒ Unconfirmed
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.