6.0.0-beta1
7/8/25

[#6606] Problem with attend.php and getByUID()
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

History
05/24/2008 05:42:26 PM Jan Schneider Comment #13
State ⇒ Resolved
Reply to this comment
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.
05/23/2008 07:12:45 PM Chuck Hagenbuch Comment #12 Reply to this comment
Ping, last chance to change/fix this for 2.2...
05/02/2008 04:04:39 AM Chuck Hagenbuch Comment #11
Assigned to Jan Schneider
State ⇒ Assigned
Reply to this comment
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).
05/02/2008 04:02:10 AM Chuck Hagenbuch Comment #10 Reply to this comment
- 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.
05/01/2008 08:53:12 AM almarin (at) um (dot) es Comment #9 Reply to this comment
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


04/30/2008 10:25:55 PM Chuck Hagenbuch Comment #8 Reply to this comment
creator_id is who saved the event into Kronolith. That's not always 
going to be the organizer.
04/30/2008 12:23:10 PM almarin (at) um (dot) es Comment #7 Reply to this comment
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.
04/29/2008 06:31:50 PM Chuck Hagenbuch Comment #6 Reply to this comment
See ticket 3965 re: organizer. I don't understand your comment about 
import vs. put.
04/29/2008 07:07:01 AM almarin (at) um (dot) es Comment #5 Reply to this comment
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
04/28/2008 08:15:17 PM Chuck Hagenbuch Comment #4 Reply to this comment
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.
04/28/2008 10:56:10 AM almarin (at) um (dot) es Comment #3 Reply to this comment
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.
04/24/2008 03:38:00 AM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
How about checking the organizer instead?
04/14/2008 03:55:44 PM Chuck Hagenbuch Summary ⇒ Problem with attend.php and getByUID()
 
04/14/2008 03:46:18 PM almarin (at) um (dot) es Comment #1
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Probl
Type ⇒ Bug
Queue ⇒ Kronolith
Reply to this comment
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.


Saved Queries