No permission check for new volume/item creation

Bug #1853062 reported by April Durrence on 2019-11-18
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

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.

tags: removed: cataloging
description: updated
description: updated
description: updated
Remington Steed (rjs7) wrote :

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) wrote :

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) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers