Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import: check if UID already exists, check which one is newest and update if necessary. #1508

Open
georgehrke opened this issue Oct 3, 2019 · 5 comments
Labels
1. to develop Accepted and waiting to be taken care of enhancement New feature request

Comments

@georgehrke
Copy link
Member

georgehrke commented Oct 3, 2019

  • Before importing, send request with all UIDs to the server. (or maybe not all but 50 at a time)
  • If it doesn't give a 404, parse the calendar-data from the server and compare the LAST-MODIFIED and SEQUENCE-properties of both.
  • If the version, the user wishes to import, is newer, update the event on the server.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@georgehrke georgehrke added 1. to develop Accepted and waiting to be taken care of enhancement New feature request labels Oct 3, 2019
@georgehrke georgehrke added this to the 2.0.0 beta4 milestone Oct 3, 2019
@tcitworld
Copy link
Member

I'm guessing you mean when importing data in an existing calendar, it makes little sense when creating a new one (UIDs are only unique in their calendar - even though there should be globally unique).

@georgehrke
Copy link
Member Author

Yes, only for existing calendars.
Although it would be nice to check for the UID globally, but that's something for way later.

@georgehrke georgehrke modified the milestones: 2.0.0 beta4, 2.1.0 Dec 6, 2019
@r2evans
Copy link

r2evans commented Mar 10, 2020

(Is this why I've been beating my head against a wall trying to update events via import?)

The iCal spec (ref 5545) says that event updates should occur based on UID and SEQUENCE (and/or based on DTSTAMP and/or LAST-MODIFIED). If we're doing an import, shouldn't one or more of those fields be referenced?

It's a common enough use-case (I believe) for a user to upload an updated (externally-provided) .ics file and expect that updated VEVENTs are correct in the calendar app.

(I think my only workaround at the moment is to either delete all updated events and reimport them, ignoring all import failures. Sadly, this means I need to know which have been changed. Lacking that, I often end up deleting all events in that category and time-span and re-importing everything. It works well enough and all other users of that calendar eventually get what they need, I think ... but it defies the RFC/spec, and I'm not 100% certain that some client won't out-smart this somehow, such as based on UID.)

@georgehrke georgehrke modified the milestones: 2.1.0, 2.2.0 Sep 4, 2020
@ChristophWurst ChristophWurst modified the milestones: 2.2.0, 2.3.0 Mar 24, 2021
@ChristophWurst ChristophWurst modified the milestones: v2.3.0, v2.4.0 Jun 24, 2021
@ChristophWurst ChristophWurst modified the milestones: v2.4.0, v2.4.1 Nov 25, 2021
@tcitworld tcitworld removed this from the v2.4.1 milestone Dec 17, 2021
@Whisprin
Copy link

Currently the API returns this error when a user tries to import an updated event invitation.

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\BadRequest</s:exception>
  <s:message>Calendar object with uid already exists in this calendar collection.</s:message>
</d:error>

In the calendar web interface it looks like this
image
There's a separate issue to improve those error messages.

@r2evans
Copy link

r2evans commented Apr 13, 2024

A related issue in server nextcloud/server#30096 was closed last year, though it is still happening. Can a dev comment please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of enhancement New feature request
Projects
None yet
Development

No branches or pull requests

5 participants