pretalx / pretalx

Conference planning tool: CfP, scheduling, speaker management
https://pretalx.com
Apache License 2.0
711 stars 200 forks source link

Changed duration of a submission is not exported into new schedule #587

Closed bentrm closed 4 years ago

bentrm commented 5 years ago

Expected Behavior

~The default duration of the currently set submission type should be reflected in exports.~

Changing the duration of a submission is possible by:

The currently set duration of a submission should be reflected in the backend planning view as well as in exports and the frontend. The WIP-view should show the currently set duration of the talk. Released schedules should show the duration that has been set at the time of the release of the schedule.

Current Behavior

~After changing the submission type of a talk the duration of the new submission type is not reflected in exports and in the frontend.~

After changing the duration of a talk already placed in the scheduling view, the new duration is reflected in the scheduling raster but not in exports.

Steps to Reproduce

  1. Create submission with distinct ~default~ duration setting ~no custom duration~
  2. Accept submission
  3. Schedule submission
  4. Check talk duration in scheduling frontend
  5. Change submission to a new ~type with a different default~ duration setting ~no custom duration~
  6. Check talk duration in backend (all fine here, new duration is shown), compare with frontend (old duration is shown)
  7. (Test in tandem with releasing the schedule for same output)

Context

We changed the acceptable duration of some talks. As the new duration is shown in the backend we did not notice this producing conflicts in the frontend exports.

Workaround

After changing the duration of a talk, remove it from the schedule pulling it into the unassigned talks row. Reschedule the talk pulling it into the previous spot of the time raster. Check and release schedule.

Your Environment

rixx commented 5 years ago

No, this is correct – once the talks have been generated, you'll have to move/modify them and then release a new schedule version for these changes to take effect. Our rule is to not modify existing schedule releases, because those are presumed to be static. This includes exports.

I agree that the WIP schedule slots should be changed, but I definitely do not want to touch existing schedules in such an update.

bentrm commented 5 years ago

The schedule has been released with a new version number. The talk is part of the released version and has been switched over to the new submission type beforehand. Comparing frontend and backend views of the same version of the schedule different talk durations are presented:

I do understand it may be necessary to change this particular talk by setting a custom duration. We were just confused by the different output in front and backend view.

bentrm commented 5 years ago

I rephrased the issue as I think this is not really an issue of the submission type but more broadly how and when the duration attribute of a submissions time slot is persisted. The workaround above seems to do the trick.

rixx commented 5 years ago

I've introduced a patch that should fix both of the issues (changed submission type duration, and changed submission duration) by updating the WIP version of those talks.

oxinabox commented 5 years ago

I am still seeing the behavour that that back-end scheduler shows the updated length, but the front-end release shows the length at time of the talks being placed in the schedule.

rixx commented 5 years ago

That is correct. Existing schedule releases are considered stable, and scheduling data in them will not be modified. This is intended behaviour. To change scheduled data, release a new version, so that tools depending on pretalx can be sure that the largest changes in a released schedule will be to the text of a submission (and we may change this later to be secured, too).

oxinabox commented 5 years ago

Yes, but the confusing part is that no release had been made yet, And it showed the new length in the back end schedule editor. Then my first release showed the original length. Disagreeing with what was shown in the schedule editor

rixx commented 5 years ago

In that case we'll need to investigate further, that's definitely a bug.

rixx commented 4 years ago

I just tried to reproduce this, and talks are updated in the schedule editor as expected.