This should be handled in voctoweb IMHO, because voctopublish does not know which conference the existing recording belongs to. Changing a conference by PATCHing a recording should raise an error when calling the API.

I'll move this issue to there.

Currently voctopublish seems to override/patch events of other conferences in case of a non-unique GUID... that's really bad.

Thats actually a feature, but we should add a warning/error when the event would be moved to another conference. The fix in these cases would be to go to the source system and choose a unique uuid.

@lukas2511 Should we add a force option in the Voctoweb Publishing API, which allows moving of an event to another conference or should such operations always be done via the Admin UI?

Currently voctopublish seems to override/patch events of other conferences in case of a non-unique GUID... that's really bad.

Thats actually a feature, but we should add a warning/error when the event would be moved to another conference. The fix in these cases would be to go to the source system and choose a unique uuid.

I've seen this issue multiple times with hand crafted schedules. Somebody just copies an existing schedule.xml, modifies human-readable values, maybe adds a video download url and imports it into the tracker. Reusing the guid from the original schedule. And I can't blame anybody for making this mistake. I wouldn't have thought that it starts overwriting talks on media either... So yea. A hard error should happen in those cases. Reusing guids in the same schedule already results in import errors iirc, so that case should already be handled.

@lukas2511 Should we add a force option in the Voctoweb Publishing API, which allows moving of an event to another conference or should such operations always be done via the Admin UI?

Since mass-moving should not happen often (or basically ever) I guess a manual operation via the admin ui or a manually crafted db query would be good enough.

Reusing guids in the same schedule already results in import errors iirc, so that case should already be handled.

@lukas2511 Where should we add this unique constraint in our systems? In the import tool? In the tracker? In both?

Reusing guids in the same schedule already results in import errors iirc, so that case should already be handled.

@lukas2511 Where should we add this unique constraint in our systems? In the import tool? In the tracker? In both?

In voctoweb itself or in the publishing scripts.

The publishing scripts are stateless. That kind of error must be handled in c3tracker or in voctoweb.

The tracker has absolutely no idea what voctoweb even is, so the only remaining solution would be an error thrown by voctoweb itself.