Comment 1 for bug 2052823

This is an interesting one, because the permissions around library settings are unusual.

The Dojo library settings editor did use VIEW_ORG_SETTINGS to specify which OUs were allowed in the context library selector. If there were none, it would display a "You do not have permission to view org unit settings" message. However, clicking anywhere on the page would load a list of settings anyway - but not display values. However, you could find the permission you were interested in, click on the History link, and see the settings values anyway.

Adding [limitPerms]="['VIEW_ORG_SETTINGS']" to the eg-org-select for the context library in the Angular doesn't have the same effect, since it will still at least force it selector to display the workstation OU. At least what you see when you click on the history link is just the setting values and history for the workstation OU.

What makes settings different is that the only limit enforced in the API are the ones imposed by the view_perm value in the library setting type. VIEW_ORG_SETTINGS is _not_ enforced server-side (though library settings are not accessible to PCRUD), so even if the Angular library settings editor were changed to refuse to display settings without VIEW_ORG_SETTINGS, one could still get at them via the API.

There could be an argument to be made about locking down access to settings (e.g., by setting view_perm for all (or at least most) staff-side library settings so that the client can retrieve only the setting values that the Angular cilent code needs and otherwise treat staff-side settings as hide-their-values-by-default.

In any event, certainly the editor shouldn't offer active edit or delete buttons for settings that the user is not permitted to edit, and at minimum shouldn't display toasts that indicate false success.

To toss out a question about the desired behavior: as far as the Library Settings editor is concerned, how control over visibility is wanted?