| Type | JIRA | Status | Title | Ref Number | Notes |
|---|
|
| NO JIRA | We no longer have pick and scan (batching editing) so staff must ask batch processing to do processes they used to do themselves and batch processing must develop scripts to do those processes. |
| Batch-Edit Starting in MG |
|
| NO JIRA | We are no longer able to batch load vendor MARC records ourselves. Batch-processing staff in LTS are currently doing this for us, but we recognize that they are quite overwhelmed. Not surprisingly, when we were able to do this work ourselves, the turn-around time was considerably shorter. We would like to be able to do these jobs ourselves again, both to offer relief to batch processing staff, and to get these records into the catalog faster. |
|
|
|
| NO JIRA | EDI invoicing – some issues with errors and loading, but some of these problems supposed to be fixed in the Juniper upgrade – Liisa’s note- Joanna and Emily are working out issues with Natalya this week, too, so perhaps some issues will be resolved even before Juniper. Liisa's additional note (11/8/21) - we haven't tested this under the full load of hundreds of invoices with the fall renewal, so EDI invoicing might be slower than we expect. |
|
|
|
| NO JIRA | Laura: Unreliable and sometimes inaccurate error messages (it’s not always clear when an import has actually failed and when it is just slow)
Jean: Single record import returns inaccurate status messages, indicating that the import failed when it fact it was successful. |
|
|
|
| NO JIRA | There isn’t a usable logging system. The page that displays after a job is run include no record ids, there are no report summaries of actions, so we have to scroll the main report and count the lines to see how many records of each type were created, edited, or had no action. |
|
|
|
| NO JIRA | Joanna: The Received history in the Receiving app cuts off at ~1000 pieces. For example, Publishers Weekly cuts off at 2019, and recent issues that we’re checking in aren’t showing up at all in the Receiving history. This is also category A. The known issues page shows this as a fix coming with Kiwi.
Jean: Not all pieces received can be displayed, if there are more than 1000 pieces in the receipt history; plus, FOLIO displays the oldest 1000 pieces rather than the most recent. Staff can add new pieces, but cannot see them in the receipt history. |
|
|
|
| NO JIRA | Reviewing problems with batch loads is extremely time consuming, making loads that have errors or failures take two or three times longer than previously. Causes: very slow query on log page (performance), underdeveloped log features (feature development). |
|
|
|
| NO JIRA | We also cannot evaluate why records were kicked out until at least one day after the load was attempted because it takes 24 hours for the data to reach LDP |
|
|
|
| NO JIRA | Slow response time, particularly for importing and overlaying bib/instance data in Inventory. Requires waiting and refreshing before continuing work. Huge impact. |
|
|
|
| NO JIRA | Margaret: Single item import is very slow, and frequently one has to wait about 15 seconds, get a pink toast, and then search by OCLC ID and wait another 15 seconds or so before the import works. (It usually does work, though, which is great!) This is the single most costly issue we have with FOLIO in terms of cataloging time.
Jean: Single record import chokes when system is stressed.
Masayo: When overlaying a record, after adding the OCLC number into “Single record import” bar it does not immediately work and needs to be done at least 3 times before it actually takes affect and the record is overlaid.
Pedro: Importing and overlaying records: it lags on the blinking ellipses for way too long, and the toasts are not reliable about whether the import was successful or not, leading to many duplicate records being created. Several minutes may elapse before the record is viewable, and occasionally the import fails altogether. This is probably the single most time-consuming and complaint-generating issue so far. Not sure if this would fall under “User Interface Issue” or “Performance Issue”, but if the time could be reduced somehow, that would go a long way toward improving productivity. This morning, Cathy and I have already experienced a new Toast coming up during an import (something like “record has been queued for import, but is not yet ready”), and I’ve spent several minutes looking for that record now. |
|
|
|
| NO JIRA | Jenn: Loading large batch loads is very time consuming. Performance requires we split into many small files which must be individually uploaded and monitored.
Jenn: We cannot load large amounts during the day or single record import begins to fail and circulation may be impacted
Lisa: Waiting on marc records to be loaded (Jenn's group is doing their best, they can only do so much when FOLIO bogs down when trying to load records |
|
|
|
| NO JIRA | Instance records with multiple holdings either take a long time to load or crash entirely. For example, Rātchakitčhānubēksā (instance hrid 311144). We have boxes of this serial waiting to be received, but we’re unable to because the browser crashes each time you attempt to load it. |
|
|
|
| NO JIRA | Scalability of functions – functions work for small records, but not for larger, e.g., transferring items between holdings is easy for a record with a small number of items but is super confusing and/or doesn’t work at all for records with larger numbers of items. Another example is data import which seems to work okay for smaller record sets, but chokes on larger ones causing system slowdowns for all users – the system does not support the capacity we need. |
|
|
|
| NO JIRA | Holdings records with large numbers of Item records attached cannot be opened readily, and in some cases not at all. See Instance HRID 351433 as an example. This stops operations to add or remove item records, or move items from one Holdings to another, in some cases making this impossible. |
|
|
|
| NO JIRA | When searching for an item record by barcode, the search result is the instance record to which the item record is attached, not the item record itself. Where hundreds of barcodes are associated with a holdings record, or there are multiple holdings records with hundreds of item records each (common situations in law libraries), the staff member has to search through the hundreds of item records to find the one they are searching for. In our Iris instance of FOLIO, the sought-after item record is at least highlighted in the item record list. In the Kiwi bugfest instance, even this functionality does not exist. We reported this on Slack. |
|
|
|
| NO JIRA | When viewing a screen of multiple search results in Inventory, it is not possible to determine which titles are electronic vs. print, nor is it possible to determine which records are suppressed from public display, without clicking open each record individually. This is a very poor use of staff time and is extremely inefficient. |
|
|
|
| NO JIRA | We cannot do queries of MARC fields that are very common because of the current performance of the SRS query API and so it is harder to evaluate records that have been loaded for problems |
|
|
|
| NO JIRA | Laura: Amount of clicking required – e.g., click to open from results, click to view, then click again to edit
Pam: Biggest deal for me bar none … that screens present in Read Only mode. Must call up the screens in Read only and click twice to get to an Edit screen. To close a record, you must also click twice. One click to close the Edit screen and one click to get off the record. I know it seems like this should not be a big deal, but it is an enormous time suck.
Margaret: After pulling up a holdings or item record, we have to click on “Edit” on the Action menu before starting to edit it. It would be faster if the system just went straight to the Edit view so we could dive right into editing. |
|
|
|
| NO JIRA | Highlighting and deleting multiple lines in the Instance record is not developed yet. |
|
|
|
| NO JIRA | The user interface for data import is painfully slow. Information on the page not very useful; when running a job, the sidebar that should be displaying what is running is usually empty, so there’s no way of knowing what’s going on. |
|
|
|
| NO JIRA | Jenn: Deleting instances not possible
Jean: Instance records cannot be deleted in FOLIO, creating a proliferation of unwanted records cluttering up the database. Unwanted records can only be suppressed (not deleted), and it is not possible to identify suppressed records within a multiple-record search result without examining each individual record. This introduces another element of inefficiency into staff workflows.
Masayo: If we have made an error or if Folio has glitched due to a lengthy loading screen, and a duplicate instance record has been created, it would be nice to be able immediately delete the duplicate instance record, especially when there is no PO attached. |
|
|
|
| NO JIRA | FOLIO does not detect duplicate order, so we have to search for each title to catch if there is an existing instance record in FOLIO |
|
|
|
| NO JIRA | EDI invoicing loads – not consistent from vendor to vendor |
|
|
|
| NO JIRA | EDI log error messages are not displaying the cause |
|
|
|
| NO JIRA | Sending PO via EDI is not yet available |
|
|
|
| NO JIRA | FOLIO does not yet import records from ArchivesSpace effectively, so the FOLIO versions of our records for archival collections are increasingly out of date. This mainly affects public services. But it also means that if I need to check something about an archival collection, I have to log into ArchivesSpace, which requires two-step authentication, to see the most recent version of the record for the collection. (Many of our print acquisitions are related to archival collections, so I work in both FOLIO and ASpace.) |
|
|
|
| NO JIRA | FOLIO does not yet interact efficiently with Aeon. This mainly affects public services, but also means updates to the status of items in Aeon are delayed, which makes it harder to find where some items currently are in the vault and retrieve them for catalog maintenance. |
|
|
|
| NO JIRA | Jean: When an instance record in Inventory has been updated, the corresponding purchase order line must be updated manually in a separate operation if the change to the instance record is significant (such as a change in the title). This is because there is little integration between instance records and purchase order lines. It would be more efficient if updating the instance record automatically caused the POL to be updated as well. A further ramification of this situation is that it is not possible to navigate directly from an instance record to the purchase order line associated with it; a separate search must be launched in the Orders app.
Masayo: The connection between Ordering app and Inventory app is only one way. |
|
|
|
| NO JIRA | Masayo: Inventory and orders app doesn’t talk to each other and therefore looking for PO is sometimes very time consuming especially when search function doesn’t work well. In Voyager we have a macro that takes directly to the PO from BIB.
Liisa: can’t link back from inventory record to the POL or PO |
|
|
|
| NO JIRA | Connecting agreement lines to PO lines – there is a limit of 10 PO lines per agreement, and at that point you can’t add anymore without an odd display issue. Emma said that this is a known issue, and it is supposed to be fixed in a later upgrade (not sure if it is in Juniper or Kiwi). In general, linking agreement lines to PO lines is great, and is added functionality with FOLIO, but it is a bit of a bother that we can’t add all the PO Lines yet. |
|
|
|
| NO JIRA | Masayo: There is no easy way to make a pop-up notification for requestor in the orders app. We have to go to Receiving app and edit there and click on the “Must acknowledge the receiving note”. This is cumbersome as we have to work with three different apps to create a Rush PO. We have to make sure that we do not miss this step otherwise requestor will not be notified especially for the print books.
Jean: When creating a check-in note in a purchase order line, if the staff member creating the purchase order line wants the note to be a pop-up note for the receiver, they have to go into the Receiving app to do this, instead of being able to do it within the purchase order line. This is inefficient.
Lisa: Not having the ability to utilize the requestor field on the POL and have it pop up to acknowledge it should be processed RUSH (A & C) The work around is to put the requestor or reserve information in the receiving note field and then go to the receiving app and check the box “acknowledge receiving note”. |
|
|
|
| NO JIRA | We still do not get any plating information displayed in the new system. (I realize we have very few plates left, but even the ones we do will not display if we needed to plate the book) I’m not sure if this is a function that will be available in the future or not. |
|
|
|
| NO JIRA | The biggest time-waster for me (that doesn’t seem like there is even a plan to take care of it) has been the lack of invoice history in Orders. There are the awesome spreadsheets that Liisa has saved us with, but like the funds, you still have to pull them up and hope the year you have checked is the year you are looking for, and if not you have to keep opening and looking. It is a chronic problem that we lose access and need to know if it was a holdings error or something we have paid for access to! Sometimes things are $30, but sometimes it is thousands of dollars. Liisa’s note: yes, this is a big time sink, as we have to refer to spreadsheets which we got from Voyager; it is especially complicated when many funds changed due to the selector team and fund changes, as well as the fact that POLs paid with multiple funds didn’t get make it into FOLIO. I frequently have to refer to multiple spreadsheets. |
|
|
|
| NO JIRA | Searching in general is very slow, especially when it ALWAYS searches what you searched prior before you can search what you really want to search now |
|
|
|
| NO JIRA | We cannot spread out the load of import data as we used to because of the complexity and poor logging of data import so we have much more work than we did before |
|
|
|
| NO JIRA | The search function is not user friendly. After adding a title search, ISBN search etc. it can be very picky. If we enter this title “ARAB CHRISTIANS AND THE QUR'AN” we get No results found for "ARAB CHRISTIANS AND THE QUR'AN ". “Please check your spelling and filters”. When we find the title, it is correct just not searchable “Arab Christians and the Qurʼan from the origins” I found this with the ISBN. This is not the only title this has occurred with. |
|
|
|
| NO JIRA | Masayo: Takes time (usually 5-10 seconds) to reset a search box for a new search
Pedro: Switching from one app to the other (e.g. Inventory to Orders or Invoices): FOLIO performs the last search on the app you’ve changed to, making you wait for that search to complete before entering a new one. The lag isn’t quite as long as it is for Import/Overlay, but it still adds time for items requiring processing across apps, like Receiving. Again, not sure if this is User Interface or Performance issue (sounds like User Interface?), but if FOLIO could skip the “impulse” to re-perform the previous search in that app, that would help a lot |
|
|
|
| NO JIRA | Cannot sort the agreement lines alphabetically; especially problematic for publishers/vendors such as EBSCO and ProQuest for which we may have 100+ agreement lines attached to an agreement |
|
|
|
| NO JIRA | Inventory app – make it easier to see when a record is suppressed. The font on the record is tiny, and not very distinctive. Would also be useful to have suppressed/not suppressed show up in results title list. (of course, the display of the results list in Inventory is a mess, but everyone knows that already) |
|
|
|
| NO JIRA | In eHoldings: Search results can only be sorted by Relevance OR Provider. It would speed things along if there were a way to sort alphabetically by title. |
|
|
|
| NO JIRA | Predictive serials check-in does not exist in FOLIO. Instead, serial issues must be manually typed in and checked in in two separate apps, Receiving and Inventory. Law libraries are serials-intensive and currency of legal information is paramount. Delays in checking in time-sensitive material are a disservice to our patrons.
Checking in: 1- I feel the system is slower for check in mostly because there are extra steps involved due to the fact that Receiving and Inventory don’t (talk) to each other. I.e.: what we mark as checked in does not automatically display in inventory unless we copy and paste it in. (It did in voyager.) 2: When trying to check in a microfilm it’s very hard to get the correct holdings record. If it’s a large title and has several holdings records it takes a long time for it to load all of the holdings records and then you have to just guess which one you want. (each holdings may have several hundred items attached) It may take 3 or 4 times to get the correct record and each time you have to wait for them all to load again. I think this is a performance issue and I hope it will be worked on. 3: It would be nice if the newer checked in issues displayed in receiving at the top, instead of the bottom. Because of the limited history sometime we cannot see what the newest checked in issues are, so we can’t see if its’s a duplicate issue until we go over into Inventory. (By then you’ve probably already added it to receiving again.) |
|
|
|
| NO JIRANO JIRA | Pedro: Macros, keyboard shortcuts, Templates, etc. (Functionality that hasn’t been developed): Laura recently showed me some commands that would be available in the Kiwi release, such as a keyboard short-cut for clicking “Save and Close”, and another for clicking on “ActionsàEdit”. This is welcome news, but we’ve had macros to do these since September. The most recent macros I’ve created will edit a Instance, Holdings, or Item record in 1 step, whether the piece fastcattable or “In Process”, and it would be nice if FOLIO had similar defaults for filling in all of the information in a certain way for certain materials. If they don’t, though, I’ve had very promising results with what I call “second-level” FOLIO macros that perform more complex routines than just moving to a button and clicking it.
Jean: Keyboard shortcuts for click-intensive operations have not been developed for FOLIO. Pedro has been generous in sharing macros with us, which has helped some.
Liisa: Too much clicking, although this has been helped with the development of macros by Pedro and others. The proposed keyboard shortcuts https://issues.folio.org/browse/UXPROD-2891 https://wiki.folio.org/display/A11Y/About+the+Accessibility+SIG are not sufficient for someone who is using FOLIO all day and doesn’t use macros very much
Pam: Just too much clicking and scrolling in general. Sound banal, I know, but it is exhausting and painful. |
|
|
|
| NO JIRA | Not knowing whether a line item is received, cancelled, returned etc. without having to scroll through so much other stuff. It would be nice if you could see this from the POL directly. |
|
|
|
|
| Laura: Amount of scrolling required. Attention required to remember which fields to populate in which record types and which fields not to populate.
Pam: Screens are not yet customizable. The pages and pages of empty boxes that we will never fill in is distracting at best. The enormous amount of intellectual and emotional energy it takes to navigate around and ignore the 90% of the display that Cornell will never use leaves us exhausted. It is very inefficient and sucks all energy from us that cannot be devoted to other parts of our jobs.
Jean: FOLIO input screens are cluttered with fields that we don’t use at CUL and are confusing to staff. For example, when creating a firm order for a one-volume print monograph, why do we have to look at fields associated with subscriptions, or electronic resources? A related issue is that some fields are duplicated in different places (e.g., there are fields for “Statistical codes” in both instance records and holdings records) and staff do not always know what information to put where.
Margaret: On the instance record and elsewhere, empty fields are allotted the same amount of space as fields with information in them. It would save space on the screen if empty fields did not display, and having fewer fields on the screen would make the record easier to read.
Liisa: The amount of space on the screen that is white and the tiny fonts make it hard to see, and the amount of blank space on every page means we have to do a lot of scrolling/mousing. It would be great if more information were visible on one screen |
|
|
|
| NO JIRA | In looking at the instance record, one has to scroll down a good distance to get to the publication information, physical description, notes, and subject headings, while the administrative information takes up a good deal of space near the top of the screen. A more compact display would be helpful, with less space allotted to administrative information. |
|
|
|
| NO JIRA | When editing/updating the Marc record, we used to highlight several lines and delete many fields at the same time but Folio doesn’t allow that. We have to delete one by one all the URLS that is exported from the OCLC for ebook orders. |
|
|
|
| NO JIRA | FOLIO does not currently support authority control, a foundation of proper library cataloging to support resource discovery. We understand this is being worked on. |
|
|
|
| NO JIRA | System-driven claiming – FOLIO does not support any kind of claiming for either continuations or monographs. We need to be able to identify and claim material that has been ordered and/or paid for but not received. |
|
|
|
| NO JIRA | Lisa: Waiting on EDI for firm orders to be deployed here at Cornell (Jenn’s team is working on this and has been successful with serial EDI. Firm is now being looked at)
Jenn: Firm Order EDI – time consuming to use email instead |
|
|
|
| NO JIRA | e-holdings: Adding notes to multiple titles at the same time (The notes app team already knows about this), it is also pretty mouse intensive to add notes |
|
|
|
| NO JIRA | The menu bar on the main page should be customizable based on the apps most needed by the user. |
|
|
|
| NO JIRA | Lack of templates – catalogers have to enter the same data repeatedly, for example, in holdings records that used to be prepopulated for them in Voyager record templates |
|
|
|
| NO JIRA | I am also affected by not being able to utilize programming scripts, (using BatchCat.dll), developed to work with Voyager, but not able to work with Folio. The structure of Folio prevents me from using what was previously created a long time ago. Again, I am forced to have to learn a new alternative and/or depend on someone else, to do the same old tasks. |
|
|
|
| NO JIRA | Some funds not mapped to FOLIO correctly, and, in cases where multiple funds are used to pay for a resource, no funds show up in FOLIO at all. This involves looking up various fund mapping spreadsheets and/or consulting with selection team leads. The problem gets fixed as soon as we pay the first invoice, so it shouldn’t repeat next year. |
|
|
|
| NO JIRA | Folio separates the 541 and the 583 from the voyager holdings records. FOLIO creates two independent lists and I was hoping there was a way to combine them back together again. |
|
|
|
| NO JIRA | awaiting a dashboard – this will be an enhancement which may be able to help organize things like renewals (particularly renewals which are not calendar-year renewals), etc |
|
|
|
| NO JIRA | The inventory user interface is clumsy and in no way intuitive. |
|
|
|
| NO JIRA | I generally find it is easy to lose track of where you are in Folio. You can click on a link and either a new tab opens or you are sent to another app or just a new window opens. The inconsistency in the way clicking on something works makes it hard to know where you are, how to get back to a previous page, or what to click out of. It feels random to me and I feel it is easy to get lost and turned around. |
|
|
|
| NO JIRA | Overall, I have to say that whenever I’m using Folio, I feel a little insulted. It is clearly not designed for experienced, production-driven users. I’m all for systems being designed for low-barrier use, but when it comes at the expense of experienced users, nobody wins. It just feels like the designers care more about this system being easy for student assistants or the causal user, and have little interest in the needs of experienced users. |
|
|
|
| NO JIRA | When you have multi-line POs: You can’t close/complete just one POL for the reason of it being returned or cancelled. Instead, you have to put notes in every place possible so it’s clear what is going on with that specific title. |
|
|
|
| NO JIRA | After all issues of a volume or year have been received, we remove them from the holdings record Receiving history and add the completed vol/year to the holdings statement. The problem with deleting the Receiving history is it only allows you to delete the pieces one by one, and takes you to the top of the screen after each deletion. You have to keep scrolling down and hitting delete for each piece, which can be very time consuming/cumbersome especially if you’re deleting many pieces. The ability to delete pieces all at once would be a nice enhancement. |
|
|
|
| NO JIRA | There is no sorting function in the Receiving app that allows for bringing the latest issue of a serial to the top of the list (Susie touched upon this in her email to you). I believe this will be coming with a future release |
|
|
|
| NO JIRA | Searching by title in the Receiving app doesn’t allow you to search alternative titles listed in the Inventory. This is because the title in Receiving comes from the PO. It would be nice if there was a link between the Receiving app and Inventory or the Orders app and Inventory, so you could search by alternative title in Receiving. |
|
|
|
| NO JIRA | The LDP is not useful for batch processing, maintenance, or trouble shooting, because it is at least 24 hours behind the live data. We can’t build database views, so we have to maintain sets of redundant SQL or create local tables that have to be rebuilt every time we need to use them; otherwise the data is even further behind the LDP tables. |
|
|
|
| NO JIRA | LDP data transfer takes too long – 14 hours, sometimes fails |
|
|
|
| NO JIRA | Time you have to wait for adding a POL to an invoice is so SLOW. (When we have a 30 line invoice the time it takes to complete is unreal in comparison to Voyager) |
|
|
|
| NO JIRA | Response time is just far too slow, particularly for resources that have multiple holdings and items. It took me about 15 minutes today to figure out a problem with the Cornell yearbook that should have taken me about two minutes. It was a little complicated, so I needed to go back and forth between holdings and item records and it loaded the records at a glacial pace. |
|
|
|
| NO JIRA | Margaret: In Inventory, index displays do not yet include call numbers. It would be a huge time saver if they did! As it is, if I want to find out what call number to use for the latest in a series of monographs classed together or bound manuscripts grouped together, after finding the records for all of them I have to open every record to see what its volume number or bound manuscript number is, so as to determine what number comes next in the sequence.
Katerina: the call number doesn't display in the list of titles retrieved |
|
|
|
| NO JIRA | Searching methods are very inadequate. In the acquisitions module searching for an invoice is difficult if you don't have the invoice number or vendor, e.g. I don't think you can search by title. |
|
|
|
| NO JIRA | The vendor name always has to be looked up - you can't just input its code. |
|
|
|
| NO JIRA | When a continuation has separate components, it is not possible to keep them in separate streams of pieces awaiting receipt, as we did in Voyager. This makes for a very messy and difficult-to-interpret display of pieces awaiting receipt and pieces received. |
|
|
|
| NO JIRA | Keyboard Shortcut suggestion: it would be great if there were a tab-related command that would switch you from the first pane to the center pane, and then to the third pane, without having to mouse-click in the spaces, or without hitting the tab key a many times to do it. |
|
|
|
| NO JIRA | There isn’t yet a way to go straight from the holdings record to the item record or instance record; instead, we have to close the holdings record first and then open the item or instance record. This introduces a slight delay. Same issue with going from the item record to the holdings or instance record. |
|
|
|
| NO JIRA | the Classification (Call number) appear earlier in the third-pane Instance view, instead of at the bottom. We have to copy that call number to fastcat a book in the next (Holdings) screen, and it’s a time-consuming pain to have to scroll nearly all the way down in the third pane to copy it. If the “Classification” section of the third pane can’t be raised up, maybe it could appear at the top, under the title, as one of the default headings? |
|
|
|
| NO JIRA | Pam: The lack of development of QuickMARC has caused us to have to develop all sorts of awkward, not time-efficient workarounds because we can’t do simple things in MARC. I mention it more to register the idea somewhere
Jenn: Folio does not offer a simple way to create a MARC record from scratch. Other avenues had to be implemented to work around that flaw. Thus affecting the time involved to complete those tasks. This flaw impacted the thesis processing workflow when there are specialized theses to be processed and cataloged from scratch. Again, having to redevelop an alternate workflow process to do the same work. |
|
|
|
| NO JIRA | The APIs are poorly documented. |
|
|
|
| NO JIRA | Deleting Item records – only with certain statuses (feature development and bugs, sometimes unwanted items are created via orders and then they can’t be deleted because they are “on order”) |
|
|
|
| NO JIRA | EDI invoices also needs more granular permissions, as it seems that some functions to do the job require full admin permissions for data upload. Jenn, Amy B, and others are already aware of this issue and are working on it. |
|
|
|
| NO JIRA | e-holdings: it would be great if we could see at a glance which packages we are subscribed to in eHoldings when we look up a title |
|
|
|
| NO JIRA | e-holdings: it would be great if when we open up the title if the packages we were subscribed to displayed at the top of the list so we didn’t have to mouse to the looking glass and time we search |
|
|
|
| NO JIRA | e-holdings: it would be great if when we open a package, the subscribed titles displayed at the top of the list |
|
|
|
| NO JIRA | too much extraneous information is displayed outside of the MARC record |
|
|
|
| NO JIRA | I was able to freely used MS Access with Voyager to assist with many of my daily/weekly tasks. I am no longer able to use my old tables/queries, or create/build new tables/queries. I am now in a learning stage of developing new avenues to do the same tasks I used to do … reinventing the wheel so to speak. |
|
|
|
| NO JIRA | Another factor that had an impact on the DBQ unit is how enumeration and chronology data is now entered into the holdings. Folio has two parts: holdings details and holdings notes. Again, we, (DBQ), had to redevelop a process of how this change effected our boundwiths and the creation of empty item records, especially when enumeration/chronology became a factor. |
|
|
|
| NO JIRA | In the instance, holdings, and item records, headings (such as “Administrative data,” “Title data,” etc.) are large, while the actual data is very small. If the headings were a little smaller, that might free up space to make the actual data larger and put it in a more substantial font, making it easier to find and read. As it is, it can be hard to find the extent statement on the instance record, for example. |
|
|
|
| NO JIRA | there is too much idiosyncratic jargon on the forms - e.g. what is "parent/child record" supposed to convey? In the Expense class box my brain hurts when I have to remember what a "one-time perpetual" purchase is supposed to mean. What the heck is a "toast"? "Pop-up" isn't good enough? |
|
|
|
| NO JIRA | I would love to have each app have its own (very pale) color for the background so I know without looking into the upper left where I am. |
|
|
|
| NO JIRA | Printing of PO and POL detail for placing an order to a vendor |
|
|
|
| NO JIRA | Printing of cancellation or claim letter to send to a vendor |
|
|
|
| NO JIRA | In the Receiving history in holdings, where we display current issues, it would be great to have the ability to rearrange the order of the pieces by clicking and dragging. For the issues to display in proper order in the public catalog, they must be in order in this field. You can only add new issues to the bottom of this field, so if we receive an issue out of order, which happens a lot, there’s much copying/pasting/shifting around issues to make them appear in order. |
|
|
|
| NO JIRA | There is no data dictionary for database fields for the source database or the LDP, none that I can find. |
|
|
