Having observed on production for 24 hours, I think this can be closed. The previous examples of SCCL and the "Monograph" mapping for NWSU are now displaying properly, and we are seeing what appears to be the correct number of numeric range mappings in the data grid.

@Jag Goraya This was fixed in DCB Admin V1.21.0 - I’m not 100% on what DCB MOBIUS fix version that aligns with so I’ve gone with 1.061 as it appears to be the next one - apologies if that’s not correct.

Possibly fixed by the changes here https://gitlab.com/knowledge-integration/libraries/dcb-admin-ui/-/commit/e547ccffb40a4c6be52829352f066c018200dc19

Which enforced the following (NOT deleted:true) logic to replace what was there before. When run against production the number of numeric range mappings jumps to 671 and all appear to be legitimate (i.e. deleted:false).

Prod before (112 NRMs)

Prod after (671 NRMs) (local run against prod server)

This also appeared to be responsible for the issue identified in this comment https://openlibraryfoundation.atlassian.net/browse/DCB-1291?focusedCommentId=474050 . Initial indications are that the change has fixed this issue but will wait to see confirmation.

RVM issue

2 valid results for “Monograph” as a from value exist.

But were not being shown in the library-specific mappings grid for NW_MISSOURI_STATE.

The logic was applied and the correct results are now being shown.

SCCL are a good example here of no numeric range mappings being shown (on production)

However MRRL have all their numeric range mappings shown. If the MRRL mappings were added after the changes in early June, it supports the hypothesis that only mappings after the changes are being shown. This seems to be because the GraphQL query cannot interpret the earlier mappings as having a false deleted value, despite them appearing to have one (see screenshot on ticket).

It would be worth attempting to re-upload mappings for a library and see what happens. This could potentially refresh the mappings and make them visible to the GraphQL query again, as time appears to be the only difference at present.

On dev, this doesn’t appear to be an issue any more

251 total NRMs

152 where deleted = false

99 where deleted = true

152 shown in Admin from Lindenwood, SLOUC, STLOUIS, WDMPL.

Also doesn’t seem to be an issue on staging.

If this hasn’t aged out of being an issue, one way of fixing it could be to re-import all the numeric range mappings that we’re not seeing again. Not sure how realistic a solution this is but it should work.

It’s possible this has actually aged out of being a problem - we’d have to check via Postman as we don’t expose the lastImported date in Admin.