...
| Field protection setting | Library/User | Works as expected? | Notes | Add a TestRail? |
|---|---|---|---|---|
| 035 9\ | Not the way I expected. I created inventory for 15 eResources with a temporary code in the 035 9\ $a(5LHFCJSP1). Then I exported those so I could match on the instance HRID to create an additional holding and item. Then I included a marc modify action linked to a marc modifications mapping that removed the 1 to have 035 9\$a(5LHFCJSP). This didn't work. I didn't see anywhere where I could override the field protections in the marc modify action or mapping profile. Here I was taking action on the incoming record. | Right now the only way we are able to make this change is to update the instances. If field protections are on update instances then we will not be able to do these batch loads in FOLIO at all. We simply don't have the resources to do this manually and there's no bulk edit. | ||
| 035 9\ | Since the marc modification didn't work on the incoming record in my other test, I tried to use an update marc action linked to a mapping. This is an update where I match on the instance HRID to create an additional holding and item and then update the marc. Right now this job is stuck with in progress. And an hour later it's still stuck. | |||
| 856 | Didn't work. I wanted to create inventory for eResources so I need the 856 to populate the Electronic access in the holdings record. The last action in the job is to modify the marc to remove the 856. This didn't happen. the log has "multiple" for instance and "updated" for srs marc. | |||
| 856 | Jenn Colt | I need to protect the 856 so that overlays with single record import don't delete our local 856s. But I need to update 856s when I import updated vendor records. Because the field protections were extended to instances, the 856 was not updated as needed and instead the 856 was duplicated. If this is implemented as is it will break ALL OUR VENDOR UPDATE WORKFLOWS. If field protections are extended to instances we need to be able to override them at the job level. We (and many others) use instance overlay to correct a large number of data import problems. We need to have an instance overlay profile that ignores field protections without having to manually turn them all off. | ||
| 035/003/001 | Jenn Colt | When I updated my records, the instance ID got turned into an 035 with the incoming 003 even though this was a pure vendor record update (ie records not exported from folio). I assume this is field protection related but I don't understand why it happened. Screenshot attached. | ||
| 035/856 | I created a marc modify action linked to a mapping that removed fields not in the protected field lists (029, 891, etc), and that removed the 856 (in the protected fields list) and tried to remove the 2-3 letters before the OCLC number. This job was a CREATE to create an instance (and implicitly a marc bib srs) only. The Marc modify action came before a create instance. This didn't work as expected. The 856 wasn't removed. The 2-3 letters before the OCLC number were removed with the 035 already present. However, the 035 generated from the 001 and 003 still had the 3 letters before the OCLC number. My expectation is that all 035s whether generated by the system or already present in the record would undergo that marc modification mapping. This is a test to try and get a profile up and running for single record import that removes fields we don't want from OCLC and those letters before the OCLC number which 5C doesn't want. | |||