For sure, free any time on Wednesday to discuss.

Something that’s come up from some of the beta testing troubleshooting: additional data would be useful to show for initial full ingest runs per Host LMS:

• timestamp of when a full ingest has been started

• length of time for full ingest to complete

• record count from full ingest

The tricky thing with this is that calculating the harvest duration based on earliest and highest recorded timestamps leads to a potentially misleading ingest run length, because incremental ingests (which can happen at a 2-5 minute interval) will raise the highest recorded timestamp if a new record is added.

So, some unknowns to consider with implementing this for full ingest cycles:

• Is there a way to capture start and end times for full harvests independently of incremental updates?

• Where is the best place to store this once-per-full-ingest information, eg, on the hostlms ingest status query record?

• Do we want to treat this as one-off, or maintain a history of (full) ingest run stats for future diagnostics, performance troubleshooting and downtime planning?

maybe we can pick this up on Wednesday before you get stuck into the detail?

Thanks for recording this requirement . It’s definitely a different thing than adding ingest sources, but let’s keep it here for now while I work out what to do with it.

• It’ll definitely be a separate ticket to extend the existing diagnostic view of Host LMS details page:

• Editing key-pairs is a different ticket again, which will apply to a less raw, more user-friendly version of the page - we’re definitely aren't ready for that yet (as you say, in the future), and it’ll need 's UX input

It does make me realise that rather than adding a separate Ingest Status page, we should just add an Ingest Status section to the Host LMS details page. I’ll update the description accordingly.

just capturing a conversation regarding the HostLMS details page with from this morning here so that it doesn’t get lost. Not sure if this is the right place for it - apologies if it’s not, wanted to put it somewhere so we don’t lose the info. Might need its own separate ticket, happy to raise if so.

Expanding the HostLMS Details Page to handle different client configs

• All HostLMS objects have a clientConfig attribute - this is currently displayed as JSON, and is different / has different attributes for pretty much every HostLMS (see screenshots). These appear to differ based on their lmsConfigClass.

• The HostLMS details page needs to be adapted to display these attributes for each HostLMS (and not display non-relevant ones).

• In the future, we will want to allow the user to edit these values as key-value pairs - to do this we’d need to add a form on the HostLMS details page.

• StLouis is a good example of a HostLMS with a quite complicated clientConfig object. The final screenshot shows how this is currently being displayed in DCB Admin - currently the information isn’t being shown at all.