No permission check for new volume/item creation

[April Durrence]

We have recently upgraded from Evergreen 3.1 to 3.3 and implemented a complete revamp of our permission structure to include a strict requirement that anyone who creates/deletes items or bibs must pass cataloging assessments. However, we have found that staff can create new volume/call# and item records with only the permissions granted to Circulator (and inherited from Evergreen Staff): https://docs.google.com/spreadsheets/d/1E9FNba6g83Reez9Lqi5sycjKBRWROZlvn5edHD-KC8Q/edit?usp=sharing

Those permissions definitely do not include CREATE_VOLUME or CREATE_COPY, which should be the permissions checked before Evergreen permits a user to create a new item or call# record, right? I don't see any other permissions that should supersede those, but am I missing something?

Here is the workflow I followed:
1. Log into web staff client with staff login account assigned to Circulator
2. Go to Cataloging>Retrieve bib Record by TCN and enter 11173473
3. Click on Add Holdings
4. Add barcode, change a few fields
5. Click Save & Exit (also able to click on Store Selected and Save & Exit from Completed Items tab)

I added new item, barcode testcirc1 here in dev database (Evergreen 3.1) for TCN

11173473: http://devappalachian.nccardinal.org/eg/opac/record/11173473?locg=1

I added new item, barcode testcirc here in next database (Evergreen 3.3) for TCN

11173473: https://nextappalachian.nccardinal.org/eg/opac/record/11173473?locg=126

This is an extremely worrisome issue for us, as we do not want staff to be able to create item or call number records without passing our cataloging assessments and being assigned to the cataloging permission groups with CREATE_VOLUME and CREATE_COPY permissions.

[Remington Steed (rjs7)]

April,

The workflow you mentioned seems to be using this API function:

open-ils.cat.asset.volume.fleshed.batch.update.override

It seems like that ends up using the CStoreEditor autogenerated function "create_asset_call_number". CStoreEditor does some permissions checking, but I'm not able to dig deep enough into it right now. Hopefully this puts someone else on the right path.

Also, are you testing with a user that has either of the UPDATE_VOLUME/UPDATE_COPY permissions?

[April Durrence (april-durrence)]

Hi Remington,

Yes, we have granted UPDATE_COPY and UPDATE_VOLUME to Circulators so that they can edit call#s, replace barcodes, change status, shelving locations, etc. But, we only want catalogers to be able to create the items and volumes because there are more ways that can go pear-shaped.

I saw your response to the listserv that you only found CREATE_VOLUME or CREATE_COPY references in serials code and not in the perl code more broadly. That is interesting and I wonder if the CREATE permissions were originally intended to be strictly for serials.

That would be unfortunate and perhaps not intuitive usage, given that CREATE_UPDATE_DELETE is a common structure used for 75+ other permissions I found: https://drive.google.com/file/d/1CYE9n-EkRJuo9SXT6mAffw0DhrdYadbD/view?usp=sharing. This is not counting a number of other common permissions that use some variation - CREATE_DELETE, etc.

Not sure how other are assigning the CREATE_VOLUME or CREATE_COPY permissions, but would be glad to hear more from others about usage, expectations, or recommendations.

[Jordan Woodard (jwoodard)]

April,

Speaking as part of the team that is redoing permission of our consortium (NTLC), I can say that we have assigned the CREATE_VOLUME/COPY permissions to Item Cat and System Admin groups in the proposed new tree. We are operating on the same basis as NC Cardinal in that we only want catalogers/Administrators that have been vetted adding items into the system.

Ill try and do some testing on my end and get back you you.

[Lynn Floyd (lfloyd)]

Just checked this against 3.4.1 with a basic Circulator and Volunteers permission (Conserto data), and it does not work correctly there either.

[Elaine Hardy (ehardy)]

See also bug https://bugs.launchpad.net/evergreen/+bug/1763811

[Samantha O'Connor (samantha-oconnor)]

This appears to still be an issue in 3.11

[Andrea Neiman (aneiman)]

Noting that this should be addressed by the work we are doing on bug 1763811.