Updated story to reference the original story in JSON output

[hlmnrmr]

What problem are we trying to solve?

Currently, there is no reference/link between an updated story that has been published and the original story. This is the case for the JSON output sent by Superdesk via the HTTP Push mechanism.

The problem with this is that client applications relying on the JSON output have no idea that an updated story is actually an update of a previously published story, they receive the story and see it just as any other new story.

Related user story: https://dev.sourcefabric.org/browse/SDESK-539

How to test this

Pre-requisite: Make sure your Superdesk instance is configured to output a JSON version of the story on publishing.

1. Log into Superdesk, create a new story and publish it
2. Check out the JSON output of the published story. It should look something similar to this
3. Update the story and publish it
4. You will see now the JSON output sent to the client looks similar to this.

Solution

The solution is obviously to include the reference to the original story as part of the JSON output of the updated story, as you can see in this Gist

With that, client applications can handle the reference in whichever way they prefer, for example:

• Overwriting the original story
• Publishing the update (and any subsequent updates) and next to it the original story

[hlmnrmr]

@superdesk/superdesk-publishing @superdesk/superdesk-core @superdesk/superdesk-australia Have a look at this. Any feedback is welcome. We would like to go ahead with this change soon, but let's see first what you guys think. Thanks!

[ahilles107]

In Publisher we identify original story by new content slug. adding new element with type "text" to associations will require small change in Publisher HTTP push handling.

[naspeh]

Here's been #723 recently

1 - Add 'original_id' to archive schema.

maybe we should use consistent schema everywhere

[hlmnrmr]

@ahilles107 You shouldn''t trust the slug, as it is not mandatory to keep the same slug for an updated story, the user could just change it and then you lose the reference.

[ahilles107]

@hlmnrmr - we know this, but so far it was only way ;) I'm 👍 for adding this as new property - not new association.

[mdhaman]

@hlmnrmr we currently have rewrite_of field in the schema which points to the original story in case of updates/rewrites. There is also rewritten_by field in the schema which points to the updated story in the original story (kind of 2-way relationship).

If we store update/rewrite_id in associations then it conforms to the ninjs schema but to search using associations we would need much stricter schema definition for associations.

I'm for using the rewrite_of field as it will be consistent schema everywhere - not new associations.

@naspeh original_id points to the original item of the duplicated item.

[hlmnrmr]

From the IPTC ninjs docs:

The associations object is a wrapper which contains news objects (other ninjs documents) that are associated with this news object. Any name can be chosen for these objects, but the name must contain only alphanumeric characters of the ASCII character set.

The origin of a story being another story falls into an association.

On the other hand, adding custom extensions is not a problem with ninjs, it is allowed by the standard as long as the IPTC schema reflects the changes, see http://dev.iptc.org/ninjs-How-To-create-provider-specific-extensions

So, yes, we could also go with a property like rewrite_of as suggested by @mdhaman instead of adding this to associations.

I think we can make an informed decision looking at the different possible use cases, where the developer working with the API to develop an app may need to:

1- Overwrite the original story with the updated story

2- Show the updated story, with a link to the original story in a sidebar

3- Show the original story in the first place and next to it, in a Timeline, all following updates

any other use case?

@ahilles107 what's exactly the usage of this in the web publisher?

[petrjasek]

there is a vocabulary for relations, we could either put these as associations or new fields: http://cv.iptc.org/newscodes/itemrelation/ eg translatedFrom, derivedFrom, previousVersion

[ahilles107]

@hlmnrmr - in publisher when we match (now with slug) this same package/text item then it replaces current article (updates it).

[hlmnrmr]

Ok, let's make a decision on this. A new custom property added to the schema seems to be the preferred way to handle this. I've checked with Vince and looking at the IPTC NewsCodes (link above shared by Petr) he's pointed out the right property to use should be evolvedFrom. Let's count thumbs up/down to that idea :-)

[petrjasek]

fixed in https://github.com/superdesk/superdesk-core/pull/745