Episode contributors: Add ability to query and add individual hosts for a specific note

Parent: [EPIC] UI extensions based on the new fields pr... (#146 - closed)

A show has a fixed, general set of hosts. These hosts are assigned via the show page.

As per the recent data-model changes, now also Episodes (=Note), can have individual Hosts assigned.

Now the Edit Note dialog should work like this:

• Pre-populate the contributors field with the hosts set in show.hosts
• Users can add additional hosts (which are not part of the general show) or remove any hosts which are usually assigned to the show

changed milestone to %1.0-alpha2 — Precise Pheasant

added P2 + 1 deleted label

assigned to @kmohrf

@kmohrf I've created this task out of the inline-task in [EPIC] UI extensions based on the new fields pr... (#146 - closed), as this is more complex. Provided additional info how this was meant to be used.

marked this issue as related to #146 (closed)

changed the description

mentioned in issue #146 (closed)

mentioned in issue aura#193 (closed)

marked this issue as related to aura#193 (closed)

added To Do label

added discuss label

@eigenwijsje we discussed this ticket with @kmohrf. It would be great if Note can be created for every Timeslot by default. So notes can already include the default Hosts from the Show. It would be good if you both could discuss any possible solution within that cycle. And is there any reason, not to do this approach, creating a Note for each Timeslot?

This sounds good to me.

We will need to change some of the fields in the Note that are currently required or define a way to derive a default value from the values of the Show and/or the Timeslot.

Great, thanks for the quick response.

After a little more thinking, some side-effect came to mind: Assuming notes are generated for one year in advance. So if your notes derives values from the show, these values are pre-populated. Now when the shows owners update some (inheritable) value of show, this update will not trickle down to episodes. This can have some unexpected side-effects. What do you think about that @kmohrf @eigenwijsje?

I think the simpler way to handle this would be to change the fields to be not required. This would require a changes in the models, serializers and views.

But I think we need to discuss this in detail soon if we really want to fit this in the current cycle.

What fields on the note would be derived from the show? If it’s primarily text, a good option may be to have nullable fields on the note. If the note API is accessed and the field value is null the value from the show is taken. If a write happens to that note field (which should only allow strings, not null values), the field is written and the fallback is therefore disabled.

This would allow us to retrieve the value from the show (thus always using up-2-date content) for as long as no one explicitly set any data for that field.

This should work for all fields where null is not actually a valid value.

More technical:

on-read: show.fieldValue if note.fieldValue is null else note.fieldValue
on-write: note.fieldValue = newValue

Basically it sounds good. But what happens if you want to assign no value (i.e. zero hosts or topics)?

Yeah this wouldn’t work for fields that are expressed through many-to-many relationships in steering. I didn’t think about the ORM implications. I guess it would still be possible to solve this somehow (e.g. through a bitmask on the note which indicates which fields have been set manually), but I don’t know if that is worth the effort.

After a brief consultation with @fm_margarethem we’ve agreed to postpone this issue to the next release so we can reach a technical consensus on how to proceed.

changed milestone to %1.0-alpha3 — Playful Platypus

removed To Do label

btw: The dashboard pre-populates the note contributors with the show hosts on creation, so this issue is technically solved (aa707763). But maybe we want to move or copy it to steering to keep the discussion on the note model flowing?

Yes, please.

closed

moved to steering#159 (closed)

removed discuss label