Summary | Problem with attend.php and getByUID() |
Queue | Kronolith |
Queue Version | HEAD |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | jan (at) horde (dot) org |
Requester | almarin (at) um (dot) es |
Created | 04/14/2008 (6294 days ago) |
Due | |
Updated | 05/24/2008 (6254 days ago) |
Assigned | 05/02/2008 (6276 days ago) |
Resolved | 05/24/2008 (6254 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
shouldn't use it. I used UID originally because that's what we have to
do with iTip.
Changed for Kronolith 2.2.
Assigned to Jan Schneider
State ⇒ Assigned
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).
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.
- 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
going to be the organizer.
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.
ticket 3965re: organizer. I don't understand your comment aboutimport vs. put.
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... howthen?
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
the creatorId is a Horde username, which might not be true for the
organizer of an invitation.
- 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
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Probl
Type ⇒ Bug
Queue ⇒ Kronolith
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.