Monograph Parts permissions must be set to Consortium level to work

[Shae]

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

[Thomas Berezansky (tsbere)]

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.

[Erica Rohlfs (erohlfs)]

Confirming this behavior in 2.9.4

[Kathy Lussier (klussier)]

I'm in agreement with Thomas on this one. Although parts are localized to a system, when staff creates one, the part is assigned to the bib record and is available for other libraries to use, similar to the way that a bib record is initially created for one library, but then available for other libraries to use. Updating a part is likely to affect several libraries that have mapped their items to that part. Deleting a part would also affect multiple libraries, though I assume (hope?) users would be unable to delete the part as long as those mappings exist.

I also agree that mapping a part should be available at any depth in the org tree. I performed a quick test, and found that if staff have the map permission assigned at the system level, they are able to successfully assign an existing part to a copy.

I would say the permissions are working as expected. However, I can see why this permission would be a source of confusion, particularly the CREATE permission, since most front-line catalogers have a need to use it. Would it make sense to improve documentation by adding a note to the permission's description field when the permission must be set at the Consortium level to work?