seminars
seminars copied to clipboard
roed314
Option on "Edit series" page to overwrite attributes of future talks
As it stands, changes made to a series' attributes do not affect previously created talks in the series. Should we have an option where such changes would overwrite the attributes of previously created upcoming talks? (We discussed this a while ago, but I'm not sure that we came to a conclusion on whether we want this or not, so I'm just recording the idea here.)
Just to clarify, this is only relevant for properties talks inherit from their series. For the new schema these are
-
access_control,access_time,access_hint,access_registration(access) -
online,room,live_link,stream_link(venue) -
topics -
languages
I think we should provide an option to apply series changes to future talks that exist (certainly for access and venue properties I think this makes sense, and probably also for topics and languages, which I'm guessing you would change only because you made a mistake or forget to include something in the first place).
Of course you can override inherited properties for individual talks, and if one has done so, maybe you don't want to change the properties for those talks? We could make it so that changes to these properties at the series level only impact future talks where the inherited value differs from the old value of the property for the series (meaning the user must have changed it at some point).
As far as implementation goes, I'm wondering if we should consider using None for the talk values of these columns to indicate that it should inherit from the series. On the U/I side, rather than copying the series value by default, we could have it simply indicate that the value is inherited from the series (but let organizers override it if they wish, including setting it to the current value the series is set to). Changes to the series would automatically be reflected in all talks that do not override the series value.
This would support more use cases and might support the default use case better. Most often I am changing a series attribute because either I made a mistake the first time (in which case I want it to effect all talks in the series), or because something about the series changed (e.g. the access control settings or the room it is held in) that I want to automatically apply to all future talks and maybe don't care about past talks (possibly room changes are an exception to this).
@AndrewVSutherland this sounds like a great idea, except for searching on it.
@edgarcosta Do we ever actually search on these? For client-side filtering it does not matter (the talk object can have None's filled in from its seminar). But I agree this is something we should think about (we could possibly deal with this in postgres including seminar attributes via a join is easy, we just want a virtual column of the form "talk.foo if talk.off is not None else seminar.foo").
Even prior to implementing this (assuming we decide to do so), I think it would be a good idea to warn the user when they modify an inherited value iand there are talks in the future that will not be affected by this change.
We had a user today who ran into a problem because they posted the livestream link for their talk on the Edit series page rather then the Edit talk page. No one could fine the link for their talk (indeed the livestream link on the series page is only ever visible to organizers).
@AndrewVSutherland: I agree that such a warning would be a good idea in any case.
I think that the general handling of this overwriting issue is something that we'll eventually need to discuss over zoom; it seems subtle to get this right.