Client


Home Prev	Chapter 12. 3.2.0 New Features	Next

Disabling of legacy XUL staff client

The legacy XUL staff client is no longer supported in Evergreen 3.2.x and the server-side installation no longer supports a direct connection by a version XUL client by default. All users of Evergreen 3.2.x are strongly urged to complete their switch to the web staff client as part of upgrading to 3.2.x.

Evergreen administrators who for some reason continue to wish to deploy the XUL staff client can do so at their risk by supplying STAFF_CLIENT_STAMP_ID during the make install step and using make_release to create installers for the staff client. However, no community support will be provided for the XUL client.

Permission Group Display Entries

In some cases, it is useful to have the ability to reorder permission, or to make only specific groups available in the permission group selector for specific Org Units. An interface has been made available to allow this.

Group Tree Display Entry Interface

Permission Group Display Entries can be reordered, added, or removed via Administration → Local Admin → Permission Tree Display Entries. Select the Org Unit you wish to edit the entries in.

Entries may be added using the Add functionality, creating entries based on permission groups that have not been added to the tree for the Org Unit you wish to add them to.

Moving an Entry

Moving an entry will shift its position up or down in the patron profile selector for a given Org Unit.

Select an entry
Press either the Move Up or Move Down button. The entry will be moved up or down, accordingly.
Click Save to save your edits.

Note

You may only move up or down entries that have sibling entries.

Removing an Entry

If you want a particular Org Unit to not have access to specific entries, you may remove an entry. Removing an entry will remove it from view. The entry will be removed from the database.

Select an entry and press the Remove button.

Adding an Entry

You may add entries from permission groups that are not currently reflected in the permission group tree. This is useful for moving entries to different parents, or making them root entries.

If desired, select an entry to be used as the parent entry.
Press the Add button.
Select a permission group from the dropdown.
If you’ve selected a parent entry, you may check the Add Root Entry box to override that parent and add the entry on the root level.
If you did not select a parent entry, the entry will be added on the root level of the tree.

Browser Client Settings & Preferences Stored on the Server

Browser client settings and preferences that should persist over time are now stored as settings on the server. This allows settings to follow users and workstations and reduces problems associated with losing settings as a result of clearing browser data.

The browser client honors setting values stored as user settings, workstation settings, and org unit settings, depending on which setting types are locally configured.

Setting Types

No setting can be both a user and workstation setting. They are mutually exclusive.
Any setting can be an org unit setting in addition to being a user or workstation setting.

Read-Only Settings

Read-only settings are useful for defining values that staff can use but not modify. For example, admins may wish to prevent users from locally modifying the grid configuration for a given interface so it remains consistent for all users.

A setting is read-only when an org unit setting type exists (regardless of whether a value is applied) and no user or workstation setting type exists.

Server-Stored Workstation Settings Workstation Admin View

There’s a new "Server Workstation Prefs" tab to the stored preferences workstation admin interface. From here, users can view which preferences are stored as server-stored workstation preferences and delete select values.

Upgrade Notes

A new permission APPLY_WORKSTATION_SETTING has been added to control who may apply values to workstation settings. Use something like the following to apply the permission to all staff accounts (mileage may vary):

INSERT INTO permission.grp_perm_map (grp, perm, depth)
VALUES (
    (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
    (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
    0 -- or 1, 2, etc.
);

Workstation setting types matching values previously stored in the browser (via localStorage or Hatch) are created as part of this feature. During upgrade, admins should consider whether any of these new setting types should be transferred to user and/or org unit settings instead. Setting type changes can be made at any time, but when a setting type is deleted all of its data is deleted, so a change in type means re-applying the settings in the browser client.

Values stored in the browser will automatically migrate to server settings as each setting is accessed in the browser client. Once migrated, the in-browser copies are deleted.

If a setting type does not exist where the browser expects one, the value is stored in-browser instead and a warning is issued in the console.

More consistent terminology in the client

Terminology has been updated in the staff client so that we consistently use the same name to describe the same thing. The following updates have been made:

The term item is now consistently used to describe the barcoded entity that had been previously been called both an item and a copy. As a result, we now use the terms item buckets, item tags, and item alerts.
The term volume is no longer used in the client, with the exception of serials, where the term is used to describe serial volumes. The term call number will replace volume in most other places.
Holdings is a more general term used to describe a combination of items and call numbers.
The term Shelving Location is used consistently in favor of Copy Location.