JOINDIN-143: Additional types of links for talk related downloads

[ghost]

Jira issue originally created by user auroraeosrose:

Often talks have items in addition to slides - maybe a zip file of code examples or a podcast or a video or something - the ability to add additional links to the talk with this information would be great.

Stories…

1. As a Speaker I want to be able to submit a collection of talk links to the API so that they are added to my talk
2. As a System Admin I would like the 'slides*link' posted to the talks endpoint in the 'links' collection to be also stored to the talks table slides*links field in order to support backwards compatibility with Web1
3. As a System Admin I would like the GET /talks endpoint to check that the talks table slide*links match the link in the talk_links table entry for the talk's slides, and update the talk*links table if not, in order that slide links updated via Web1 are replicated to the API responses
   …
4. What should happen if the API talks endpoint receives a request with both slides_link and an entry in the links collection of type slides?

[ghost]

Comment created by afilina:

Here is how it looks like in the pull request.

[ghost]

Comment created by lornajane:

Here's the commit from Anna's pull request, which I think is a good start but we need a more normalized db storage so I closed her pull request: afilina/joind.in@07d7754 The commit is here because I think we should keep the frontend bits if we can, it's a good interface. (Anna if you don't want to pick this up, feel free to unassign the issue from yourself and someone else can look at it, thanks for your input!)

[ghost]

Comment created by afilina:

I'll be busy between the CfP and ConFoo, so I unassigned it.

[ghost]

Comment created by lornajane:

Unassigned this issue in case anyone else wants to work on it (John just let us know if you're actually still doing something on this)

[ghost]

Comment created by gargoyle:

When you say "normalised storage", do you mean database normalisation or the data format of the Links column?

I don't think normalising the db by having a talks_links table (or similar) offers any advantage, and just makes the whole thing more complex.

If the links are never going to be used outside of the context of displaying them in an individual talk record, I don't see the harm in embedding them in the talks table row.

[ghost]

Comment created by lornajane:

The links need to go into a separate table, comma separated value columns always come back to bite you in the end, honestly :) I could live with max 3 links and 3 new columns for them if that's easier :)

[ghost]

Comment created by lornajane:

This has been idle for a while so let me restate what we're asking for here:

Additional storage to allow us to have multiple links against a talk. These should be of various types, I can immediately think of slides/video/handout/resource but let's stay flexible. The API then needs to support those multiple resource types (to add them as well as to display them) and also support showing the existing slides_url field as one in that collection of links. I suggest we have a talks/42/links collection for this.

[ghost]

Comment created by tog:

I've picked this up at the PHP NW 14 hackathon. Will be working through it over the coming weeks as I can find time.

[ghost]

Comment created by tog:

Apologies for not getting any further on this since October. New project came along. Hoping I might be able to look at this in March, but feel free to re-assign in the meantime if anyone else can take a look at this.

[ghost]

Comment created by lornajane:

We've now got storage for the types of links that can be created, in a table called talklinktypes. Please see the subtasks for what remains to be done on this task

[ghost]

Comment created by Exussum:

a few questions here.

The new table has been made, buy its just a pk and a description ?

The links table is directly on the talks table ? Surely another table is needed (multiple links per talk, eg a slideshare and a youtube video)

A side questions slightly related to this, on the vagrant box why are foreign keys not used ?

[ghost]

Comment created by akrabat:

{quote}The new table has been made, but its just a pk and a description ?{quote}

talk*link*types is the list of available types of links in the same way that languages is the list of available languages.

{quote}The links table is directly on the talks table ? Surely another table is needed (multiple links per talk, eg a slideshare and a youtube video){quote}

See Sub task 1 (https://joindin.jira.com/browse/JOINDIN-648)

{quote}A side questions slightly related to this, on the vagrant box why are foreign keys not used ?{quote}

If i was to guess, it's because when the project was started, all the tables were MyISAM.

[ghost]

Comment created by lucianoqueiroz:

How this task is going? Anyone working on it?

[ghost]

Comment created by heiglandreas:

Doesn't look like someone's at it. If you want to, go ahead and grab it ;)

[ghost]

Issue was closed with resolution "Fixed"