Monograph Parts permissions must be set to Consortium level to work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I've been working with a site that's trying to implement monograph parts. The user testing this had ALL the monograph part permissions:
MAP MONOGRAPH PART
CREATE MONOGRAPH PART
UPDATE MONOGRAPH PART
DELETE MONOGRAPH PART
They couldn't add, edit, delete, etc.. nothing with monograph parts. Their depth in permissions was set to System so I increased it to Consortium and then it worked. This is something so localized to a branch or system, I'm not sure why you'd want staff members creating monograph parts universally. Maybe this is just how it is supposed to work but it seemed buggy to me. If someone could take a look and let me know, that would be great. I've noticed this same issue with a few other permissions that don't seem like they should have to be at Consortium level but I'll report those separately.
This is at version 2.4.3.
Thanks,
Shae
tags: | added: parts |
tags: | added: cataloging |
tags: |
added: cat-parts permissions removed: cataloging parts |
My view:
CREATE/ UPDATE/ DELETE work on elements that are bib-level, and thus not tied to a specific org unit. Because of this I believe that they should, in fact, only grant anything when applied globally.
MAP is "assign part to copy" and thus should probably be looking at the copy's circ and/or owning library instead of looking globally.
Thus, three of the four permissions are likely working as needed, and the last is the only one needing to be changed.