[REPO-1979] REST API: Add support for IN_PROGRESS in renditions listing Created: 03-Feb-17  Updated: 11-Jun-20

Status: In Progress
Project: Repository
Component/s: REST API
Affects Version/s: None
Fix Version/s: VB: REST API: V1 Advanced

Type: Story
Reporter: Gavin Cornwell Assignee: David Caruana
Resolution: Unresolved Votes: 0
Labels: ACA, ADF, MediaManagement, triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causes ADF-3953 ppsm files are not being previewed su... Open
relates to REPO-446 Monitoring of long running asynchrono... Open
relates to REPO-223 REST API: Retrieve In Progress Rendit... Review
Work Funnel: Feature
Epic Link: REST API - Renditions


As a developer using the REST API I want the status property to reflect the fact that the rendition is being generated so that my client doesn't make a further request to generate it and receive a 409 response.

Background Information
The Media Management module adds in the capability to track renditions progress and uses the IN_PROGRESS status for that so this endpoint should be consistent. We should migrate this capability from the module into the core of the repository.

Acceptance Criteria

  • When a rendition is being generated an IN_PROGRESS status is returned
  • OpenAPI spec is updated
  • Automated tests have been updated
  • Current Media management module can be successfully installed and executed against this update of the repository

Comment by David Draper [X] (Inactive) [ 03-Feb-17 ]

I think that this data should be in the main nodes response (not in the rendition specific API). A client needs to know in a single call for nodes to display whether or not each item (I think this is covered by REPO-1978):

  • has a rendition available to use
  • has a rendition being generated
  • cannot have a rendition generated
  • can have a rendition generated, but that one has not been requested

The data should be in the form of map, i.e.

renditions: {
  doclib: "INPROGRESS",
  impreview: "AVAILABLE"


renditions: {
  doclib: "IMPOSSIBLE"
  imgpreview: "IMPOSSIBLE"

...sensible/better wording should be used

Comment by Gavin Cornwell [ 06-Feb-17 ]

Agreed, generally representation are re-used across the API so if the listing response was enhanced with support for IN_PROGRESS then by definition this would be exposed by the include mechanism described in REPO-1978.

Having said that we haven't exposed a listing representation via include before and you're also proposing a different representation be used i.e. a map, I presume that is to make client parsing simpler, thus avoiding iterating through a list and "finding" the rendition you're interested in?

Comment by David Draper [X] (Inactive) [ 06-Feb-17 ]

Yes, but I think the requirement is more related to REPO-1978 rather than this one. The requirement of a map is to avoid code like this:

let renditionData = get(this.props.item.entry, "properties.cm:lastThumbnailModification", "");
if (renditionData)
   hasRendition = renditionData.some(function(rendition) {
      return rendition.indexOf(renditionId) > -1;
   }, this);

...that is currently necessary to determine what thumbnails are available.

Comment by Derek Hulley [X] (Inactive) [ 31-Jan-18 ]

David Caruana
Can you check this issue and determine if it also covers the use case in REPO-223, please?
What other acceptance criteria can be added?
Can this be completed before we introduce a queue around transformations?

Comment by Gavin Cornwell [ 01-Feb-18 ]

Please note that an implementation of handling IN_PROGRESS renditions is already available within the Media Management Module. However, the implementation makes a few low level changes to the action service so it wasn't bought over into core in the first round of recent REST API development.


Comment by David Caruana [ 02-Feb-18 ]

Derek Hulley [X] - this issue does not cover REPO-223. We should raise a new ticket to track a failed rendition status (this is currently not done in the repo, there is no apparent persistent location to store a failed status so requires core action service changes).

The comment from Dave re: adding rendition state to node representations is outside the scope of this ticket and should be tracked in REPO-1978.

This can be implemented prior to introducing the platform queue mechanisms by migrating what is already done in the Media management module as the starting step.

A separate ticket should be raised for the Media Management team to remove their implementation of IN_PROGRESS in favour of the ACS 6.0 core implementation when ready. Presumably this would result in a new Media management module for ACS 6.0 onwards. We are not dependent on this, as the existing media management module must continue to run on ACS 6.0, as part of acceptance criteria on this ticket.

Comment by John Knowles [X] (Inactive) [ 06-Feb-19 ]

Jan Vonka - does ATS impact this in any way?

Generated at Tue Aug 11 23:14:25 BST 2020 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.