Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Ticket

Description

Status

1

https://issues.folio.org/browse/UIIN-2728

Prevents ECS users from viewing other tenants' locations in the Effective location (item) facet.

Status
colourGreen
titleapproved

2

https://issues.folio.org/browse/UIPFI-138

Prevents ECS users from viewing other tenants' locations in the Effective location (item) facet (Find instance plugin)

Status
colourGreen
titleapproved

3

https://issues.folio.org/browse/UIPFI-140

Users are not able to identify the searched effective location in the corresponding facet

Status
colourGreen
titleapproved

CSP #2 - March

...

8th

Ticket

Description

Status

1

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUIMARCAUTH-363

Facet counters do not update when searching and navigating through results in the MARC authority app, which prevents users from accurately interpreting search results

Status
colourGreen
titleapproved

...

Ticket

Description

Status

1

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMSEARCH-686

Work required for Folijet’s bugfix related to consortial holdings accordion in ECS. Retrieving additional fields for holdings/items.

Different solution designed; no longer need this ticket.

Yellow
Status
colour
titleRequested approvalN/A

2

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMSEARCH-689
- placeholder story while waiting for confirmation

In the preexisting algorithm, the logic checked the call number against the algorithms for all types - I believe based on the marc4j library. Meaning, call numbers were interpreted based on the "valid" parameters built into the algorithm. Dewey numbers with alpha characters were already not sorting based on Dewey rules - they were being interpreted as LC call numbers. This validation became more apparent when call numbers were split by types - the existing validation rules were being applied, but instead of checking against ALL types, the logic checks against the assigned type. Meaning, call numbers with Dewey types that "failed" this validation are not getting the shelving order assigned, and therefore are not showing up in results.

  • Requesting feedback on 2/29/24: Assumption is that we will need to remove validation.

  • Blocking upgrades

Status
colourYellow
titleawaiting feedback

3

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMSEARCH-692

Work required for Folijet’s bugfix related to consortial holdings accordion in ECS. Retrieving additional fields for holdings/items.

Replaces initial work for MSEARCH-686

Status
colourRed
titleneeds discussion

4

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMSEARCH-693

Work required for Folijet’s bugfix related to consortial holdings accordion in ECS. Retrieving additional fields for holdings/items.

Replaces initial work for MSEARCH-686

Status
colourRed
titleneeds discussion

Upgrade issues

Ticket

Description

Fix

1

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMSEARCH-670

Call numbers showing up in other browse by type options. - is this related to the type inheritance issue?

Script

2

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODELINKS-223

Running into an issue with authorities migration in Poppy upgrades

Existing script

3