...
Issue | Reported Date | Temporary/Workaround Solution | Solution Status and Date |
---|---|---|---|
Preserving Circulation Demographic data | 1/17/23 | Preserving Circulation Demographic data
| Workaround in place local_core.circ_snapshot3 updated automatically daily at 7am unresolved, workaround in progress |
Call Number Order on Holdings-Level Call Numbers | -see https://issues.folio.org/browse/UXPROD-3496 -this is a feature that allows you to order your lists of items in correct call number order with the holdings level call number -Currently, we are unable to sort holdings record results by correct LC call number order. For item records, we can do this through the “effective_shelving_order” field in the inventory_items table (and with applying the “collate “C”” function in the ORDER BY part of the query). We can’t do this with holdings records. It never comes out right. We had a JIRA ticket for this work, but we can’t find it. | Unresolved | |
Item Level Call Number no longer on some derived tables | -derived tables loans_items and items_holdings_instances no longer capture the item level call number, because the inventory_items table (which they reference) has changed -The derived tables “items_holdings_instances” and “loans_items” no longer contain the item call number, because the source table (inventory_items) no longer has that field. Instead, inventory_items has the call number components parsed out of the data blob (prefix, suffix and call number core). These components need to be included in a revision of the scripts for the two derived tables. Also, the item_ext derived table has been updated to include the parsed-out call number components, but still retains the non-functional item_level_call_number field. | Unresolved -Natalya working on updating items_holdings_instances for Orchid 1.6 -Natalya to ask Angela about loans_items | |
Orchid Breaking Changes for Subjects and Series | 1/3/23 | Breaking changes for Orchid release: updates to instance records (subjects and series) to capture changes associated with authority control Cornell goes to Nolana - end of Feb, beginning of March Cornell goes to Orchid - hopefully before Fiscal Year Rollover
The changes are mainly related to two fields: "properties": { series field is now an array of objects: "properties": { | Need to test |
Finance_Budgets table issue
| 1/17/23 | Finance_Budgets table issue
| Workaround in place Bug submitted, to be fixed in Poppy release |
Fund Balance Discrepancy | 1/12/23 |
| Unresolved Bug submitted, to be fixed in Orchid release |
In the public.srs_records table, the column external_id is actually the instance_id | None needed | Fixed | |
In the public.srs_marctab table, all ids are in uuid format, and this does not match the format of ids in other tables | Cast all ids from tables that connect to srs_marctab as "::uuid" Example code when joining srs_marctab AS sm to srs_records AS sr LEFT JOIN srs_marctab AS sm ON sr.id::uuid = sm.srs_id | None | |
In the public.srs_marctab table, the instance_id column is incorrect and should not be used. | The srs_marctab table can be connected to the public.inventory_instances table via hrid, and the instance_id can be brought in from the inventory_instances table. Example code: SELECT WHERE sm.field = '000' Another way to get data from the srs_marctab table and insert a correct instance_id is via the srs_records table. Example code: SELECT --NOTE that all ids in the srs_marctab table have been cast as uuids, so cast the OTHER table's id as ::uuid
| Fixed, the instance_id column from srs.marctab has been corrected as of 9/12/22. | |
public.audit_circulation_logs did not start recording loan renewals until December 17, 2021. |
| The circulation_loans table has a record of renewals (renewal count) starting 7/1/2021, but note that these are only for items checked out since 7/1/2021. | None |
public.notes table does not contain any data, and will impact any queries using this table | updated 10-17-22 | None | Resolved, but still has the contents field data that includes HTML tags -Sharon to ask Nassib |
Invoice and fund tables migrated from Voyager show amounts 100 times greater than the actual amount | 10/17/22 | The data type for monetary amounts in Voyager finance tables was "Text," but when migrated to Folio was turned into "numeric." The decimals were stripped out – this means that when using Voyager historical data for funds and transaction amounts, divide your results by 100. Be careful to check your results for all queries that involve monetary values from Voyager. | No fix foreseen |
...