There's more...

It would make sense for us to give this permission to the Library user and Library manager 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 addon modules should not be directly customized, since they will be reloaded at 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 allows only to add, not to remove. A more flexible approach can be to uncheck the Active flag to false on the particular ACL lines, to disable them. It 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.