Uniqueness of event/todo ID is not enforced



14 years ago
12 years ago


(Reporter: arusso, Assigned: mostafah)





14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

IDs are unique when generated, but there is no ex-post check. It is possible for
instance to load two copies of the same file so that all events have exact
duplicates (including IDs).

Reproducible: Always
Steps to Reproduce:

Comment 1

14 years ago
There are functions which assume that IDs are unique, like deleteEvent(id) and
fetchEvent(id) (typicaly some of the methods of the calendars container). Since
there is no guarantee that this is the case there are a few approaches to fix
the issue:

1) We enforce uniqueness at calendar level (refusing to load events with
duplicate IDs or regenerating duplicate IDs). In this case all methods which use
only id, but without reference to the calendar/server (e.g. calendar container
fetchEvent/deleteEvent) should be depracated. In practice a second argument
should be requried.

2) We enforce uniqueness at the calendar container level. So IDs are unique
among all events in all calendars. 

2a) One way is to have unique calendars/servers id and "merging" this
calendar-id-component into the individual event id. Events with ids which "do
not conform" are regenerated. 

2b) Another approach is to refuse to load events which have already been loaded
into the container from other servers (but I think it might be dangerous).

I am in favour of 2a. Also a server-level id would make it easier to refer to
calendars/servers. Now the "server string" (e.g. the path for flatfile backends)
is used, which IMO is a suboptimal approach.  
How can you currently get duplicated IDs?

Comment 3

14 years ago
Copy the ics file. Create a second calendar and point it to the copy.
imho, the events with the same ID are the same events, so they can have the same ID.
What to do with modifications is a question that i can't yet answer.

*** This bug has been marked as a duplicate of 216298 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Mass move of libxpical bugs to the Internal Components, per ctalbert.
Component: libxpical → Internal Components
The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!
QA Contact: gurganbl → base
You need to log in before you can comment on or make changes to this bug.