Feed Source Summary

[br648]

Checklist

• Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
• Any modified or new methods or classes have helpful JavaDoc and code is thoroughly commented
• The description lists all applicable issues this PR seeks to resolve
• The description lists any configuration setting(s) that differ from the default settings
• All tests and CI builds passing

Description

Update to provide a new end point which will return all feed source summaries as required by the UI.

Companion PR: ibi-group/datatools-ui#981

See: https://ibisolutions.atlassian.net/browse/DT-315?focusedCommentId=251321

[binh-dam-ibigroup]

@br648 I think the main bottleneck is that the same query is still repeated for each project, and as a result, the number of times we hit Mongo doesn't change overall. Could you see what happens if getFeedVersionFromPinnedDeployment and getFeedVersionFromLatestDeployment grabbed all projects at once?

[philip-cline]

Couple properties we need in the FeedSourceSummary for the front end:

• labelIds
• latestValidation to show this portion of the FeedSource table:

For this section, we need to query the latest feedVersion - is that something that should be wrapped up in the project query for efficiency?

[br648]

@philip-cline I've made an update to include feed source label ids.

The latest feed version should already be available as part of the information returned by feedsourceSummaries. To keep the payload to a minimum, only the required values from the latest feed version are returned. See FeedSourceControllerTest.canRetrieveDeployedFeedVersionFromLatestDeployment() and FeedSourceControllerTest.canRetrieveDeployedFeedVersionFromPinnedDeployment(). Let me know if additional values are required.

[philip-cline]

@br648 Would it be easy to include projectId in the summary data? Any feedsource update after getting the feedsource summaries requires the project ID to make an update to the feedsource. I could update all the front end methods to include this, but it seems easier to just include it in the data in the first place

[br648]

@br648 Would it be easy to include projectId in the summary data? Any feedsource update after getting the feedsource summaries requires the project ID to make an update to the feedsource. I could update all the front end methods to include this, but it seems easier to just include it in the data in the first place

@philip-cline I have added the project id to the feed source summary.

[philip-cline]

It seems like it will be easier on the front end to integrate these changes if we maintain some of the same structure as previous. Could we use the following structure:

{
  "projectId": "...",
  "id": "...",
  "name": "...",
  "deployable": true,
  "isPublic": false,
  "lastUpdated": "...",
  "labelIds": [],
  "deployedFeedVersionId": "...",
  "deployedFeedVersionStartDate": "...",
  "deployedFeedVersionEndDate": "...",
  "deployedFeedVersionIssues": X,
  latestValidation: {
  		"feedVersionId": "...",
  		"feedVersionStartDate": "...",
  		"feedVersionStartDate": "...",
  		"feedVersionIssues": "..."
  		
  }
}

[br648]

@philip-cline Structure updated as requested.

[philip-cline]

Thanks for the update @br648! I just made another small commit changing the field names so that they require less work on the front end

[philip-cline]

This is looking good to me! I have been able to create a front end PR to test it out and works well!

[binh-dam-ibigroup]

Inclined to approve, as the loading is much faster with the UI PR, but I would make sure labelIds is non-null.