Batch Importer (Bib/Acq) (UXPROD-47)

[UXPROD-661] Create interactive log-summary of batchload results, initial prep Created: 25/May/18  Updated: 16/Sep/20  Resolved: 16/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q4 2019
Parent: Batch Importer (Bib/Acq)

Type: New Feature Priority: P3
Reporter: Ann-Marie Breaux (Inactive) Assignee: Ann-Marie Breaux (Inactive)
Resolution: Done Votes: 0
Labels: cap-mvp, data-import, delimited_files, marcimport, po-mvp, q4-2019-at-risk, q4-2019-split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-47 Batch Importer (Bib/Acq) Analysis Complete
is defined by MODSOURMAN-212 Backend requests for View All Logs sc... Closed
is defined by MODSOURMAN-215 Remove logDto and jobExecuitonDto ent... Closed
is defined by MODSOURMAN-227 Implement journal service rest api Closed
is defined by UIDATIMP-304 Update BE calls for retrieving logs a... Closed
is defined by MODSOURMAN-160 Sequence of records in the log does n... Closed
is defined by MODSOURMAN-219 Design and implement journal service... Closed
is defined by MODSOURMAN-222 Create API for getting logs with sort... Closed
is defined by UIDATIMP-285 Create "view all" log screen Closed
is defined by UIDATIMP-286 Search details for the "view all" log... Closed
is defined by UIDATIMP-287 Filter details for the "view all" log... Closed
is defined by UIDATIMP-301 Support ordering when retrieving logs Closed
is defined by UIDATIMP-310 Update query for sorting by numeric f... Closed
Relates
relates to UXPROD-2200 Create interactive log-summary of bat... Draft
Epic Link: Batch Importer (Bib/Acq)
Analysis Estimate: Medium < 5 days
Analysis Estimator: Niels Erik Nielsen
Front End Estimate: XXL < 30 days
Front End Estimator: Taras Tkachenko
Front-End Confidence factor: Low
Back End Estimate: Small < 3 days
Back End Estimator: Oleksii Kuzminov
Estimation Notes and Assumptions: This issue covers the display of import logs in a UI. By "interactive" I assume the description means that the log report is filterable and sortable? More elaborate configuration options, like choice of display columns or cross tabulating data would obviously have a significant impact on the estimates.

I'm not immediately clear if this issue also covers the writing of logs for display. The estimate assumes that it does but I have no up-front clear view of the complexity of say, error record reports with resolution info. Could potentially be quite involved before all possible error scenarios are covered. Users or developers with experience in this kind of applications might be able to qualify these doubts and assumptions and thus the estimates. Confidence is set to low.
Development Team: Folijet
PO Rank: 87.9
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: Leipzig (ERM Aut 2019): R4
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

After batch load is completed, create an interactive results log/dashboard/report, with data such as:

  • load stats (date, time, # actions)
  • new records created
  • existing records merged or overlaid with new data
  • deleted record, or records marked for deletion
  • problem/error records that were set aside during the load, with info about the problem to allow the user to resolve

Comments from Jon Miller/Chicago in the context of Data Migration, July 2019:
I added support for the Source Record Storage module to my general purpose file loader app https://github.com/jemiller0/Folio. For loading using the API it uses the batch API. It is the first test case that I have that makes use of an API that accepts and array of objects. It's a work in progress. It doesn't do much with regard to handling the HTTP response at this point (for example, parsing out the error messages)

Comments from Lisa McColl/Lehigh
I know we've had conversations on what constitutes an error. A "success" could be successful from the computer's point of view, but not what you intended. An "error" could mean the system failed or that intended consequences were recognized. I definitely think errors should be reported, so I don't think this is an interface issue, but I would like to be clear for system behavior as to what constitutes an error. Do we have this worked out? If not, do we need to work it out now? Thank you! (edited)



 Comments   
Comment by Cate Boerema (Inactive) [ 11/Jun/18 ]

Ann-Marie Breaux and Holly Mistlebauer, I was just going through features and noticed that this looks like an in-app report. If so, I guess it should be tagged with appreport and added to the Reporting SIG Master Spreadsheet.

Comment by Anya [ 29/Mar/19 ]

Comments from March Meeting : Errors/non-loads are the most critical. Could be less interactive to start

Comment by Cate Boerema (Inactive) [ 18/Nov/19 ]

Hi Ann-Marie Breaux I see this is still in draft. Do you think it at risk at this point? If so, please add the q4-2019-at-risk tag. Thanks!

Comment by Ann-Marie Breaux (Inactive) [ 16/Dec/19 ]

Remaining Q4 2019 open stories and tasks split and moved UXPROD-2200 Draft

Generated at Fri Feb 09 00:09:27 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.