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:
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?
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 ***
Status: UNCONFIRMED → RESOLVED
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.