Batch Importer (Bib/Acq)
(UXPROD-47)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q3 2020 | Parent: | Batch Importer (Bib/Acq) |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Ann-Marie Breaux (Inactive) | Assignee: | Ann-Marie Breaux (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | Showstopper-Cornell, data-import, q3-2020-stretch, support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Epic Link: | Batch Importer (Bib/Acq) | ||||||||||||||||||||
| Development Team: | Folijet | ||||||||||||||||||||
| PO Rank: | 101 | ||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R3 | ||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R2 | ||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||||||||||||||
| Description |
|
When a data import is taking too long (and may have died without an indication), user should have the ability to manually stop that data import job. TBD: when a job is stopped, what should happen?
Question - what about existing jobs that are stuck (see EBSCO demo account for examples). Can they be retroactively updated so that they can be stopped? |
| Comments |
| Comment by Kelly Drake [ 31/Aug/20 ] |
|
Ann-Marie Breaux, both MSU and Leigh are now running into this issue in their production environments. Would it be possible to upgrade this to a bug - and a P2 at that, since the only workaround is that they have to run their updates in their Test environments and if they fail, then not run them in production at all. |
| Comment by Kelly Drake [ 15/Sep/20 ] |
|
| Comment by Ann-Marie Breaux (Inactive) [ 15/Sep/20 ] |
|
Hi Kelly Drake Yes, that's the intention. We just haven't written the actual front-end and back-end stories to deal with this feature yet. |
| Comment by Anya [ 15/Sep/20 ] |
|
would second the bug ... |
| Comment by Ann-Marie Breaux (Inactive) [ 15/Sep/20 ] |
|
Hi Anya and Kelly Drake I got with Kimie today and figured out a UI model that we can copy to handle this. Clean UI and MOD stories have been created. If you would like to create a bug, please link to the above UI and MOD issues. Thank you! |
| Comment by Lisa McColl [ 16/Sep/20 ] |
|
Bug created: https://folio-org.atlassian.net/browse/UIDATIMP-655 |
| Comment by Karen Newbery [ 22/Sep/20 ] |
|
It is very important that we have a way to kill jobs that have stopped from errors. Based on feedback from other implementers in production, they frequently run into an issue where a job has errored out. We would need to be able to kill jobs that act that way. |
| Comment by Ann-Marie Breaux (Inactive) [ 28/Sep/20 ] |
|
Hi Karen Newbery Yes, we're going to try to squeeze this into the Honeysuckle release. Stay tuned! |