Event upserts via GUIDs should not move an event to another conference

[lukas2511]

Event upserts via GUIDs should not move an event to another conference

[Kunsi]

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.

[saerdnaer]

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?

[lukas2511]

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.

[saerdnaer]

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?

[lukas2511]

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.

[Kunsi]

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

[lukas2511]

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