[#6675] calendar/import method doesn't track creator_id
Summary calendar/import method doesn't track creator_id
Queue Kronolith
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners Chuck Hagenbuch <chuck (at) horde (dot) org>
Requester almarin (at) um (dot) es
Created 05/02/2008 (9 days ago)
Due
Updated 05/05/2008 (6 days ago)
Assigned
Resolved 05/05/2008 (6 days ago)
Attachments api.php.patch Download
Milestone
Patch

History
05/05/2008 Chuck Hagenbuch Comment #2
State ⇒ Resolved
Assigned to Chuck Hagenbuch		 Reply to this comment
This doesn't seem right to me. I think we want to make the same change we made to _kronolith_put - check if the event exists on the calendar we're importing to. I've done that in CVS.
05/02/2008 almarin (at) um (dot) es Comment #1
New Attachment: api.php.patch Download
Patch ⇒
Milestone ⇒
Queue ⇒ Kronolith
Summary ⇒ calendar/import method doesn't track creator_id
Type ⇒ Bug
Priority ⇒ 1. Low
State ⇒ Unconfirmed		 Reply to this comment
Scenario:

An invitation is sent by USER_A to USER_B. USER_B accepts it in IMP and selects "Add to my calendar" the event attached. An new event is created in backend, but creator_id is USER_B, instead USER_A.

That behaviour doesn't occur when you import an entire iCalendar, throw WebDAV, for instance.

That happens because IMP uses calendar/import API method, which is focused to import only one event given in iCal format. When you publish a calendar throw WebDAV, calendar/put method is used.

So, I think that calendar/import should respect creator_id as calendar/put does.

I attach a patch to show a way to solve it. Mainly I use a similar instruction found in _kronolith_put function, line 556:

  // Don't change creator/owner.
  event->setCreatorId($existing_event->getCreatorId());