It would make sense for us to give this permission to the Library user and the Librarian groups defined in the Creating security groups and assigning them to users recipe. If you followed that recipe, it's a good exercise to then follow this one, adapting the group identifiers to the Library ones.

It's important to note that access lists provided by add-on modules should not be directly customized, since they will be reloaded on the next module upgrade, destroying any customization that could have been done from the GUI.

To customize ACLs, two approaches can be used. One is to create new security groups that inherit from the one provided by the module and add additional permissions on it, but this only allows us to add permissions, not to remove them. A more flexible approach would be to uncheck the Active flag on the particular ACL lines to disable them. The active field is not visible by default, so we need to edit the tree view to add the <field name="active" /> column. We can also add new ACL lines for additional or replacement permissions. On a module upgrade, the deactivated ACLs won't be reactivated and the added ACL lines won't be affected.

It's also worth noting that ACLs only apply to regular models and don't need to be defined for Abstract or Transient models. If defined, these will be disregarded, and a warning message will be triggered in the server log.