Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Preventing access by staff and patrons of ADM library to be removed

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Desired Outcome Goal:
    As part of removing the abc50 ADM, prevent access to the server by ABC staff and patrons.

    Procedure:
    **STAFF ACCESS**

    In regard to ABC staff accessing the server via the GUI....

    Currently, the ABC staff are primarily accessing abc50. Once abc50 is gone, that will be a non-issue. If they also access of other ADMs (such as def50), it would seem that their GUI log-in Staff Privileges/Access Rights for abc50 would not permit any kind of update.
    But, if ABC staff are permitted to access def50 and the desire is to prevent this, their staff log-in's can be removed as follows:

    * Right-click on the skeleton key at the bottom right
    * Select "Staff Privileges"
    * Highlight a ABC User-ID and click on "Delete User".

    The following SQL can be used to produce a list of the abc50 User-ID's:

    > s+ pwd50 <where pwd50 is the $pw_library>
    SQL> select Z66_REC_KEY from z66 where Z66_USER_LIBRARY = 'ABC50' order by Z66_REC_KEY asc;

    Preventing GUI access for all ABC ip-addresses can be done in $alephe_tab/server_ip_allowed.

    Let's say that the range of ABC IP-addresses is 132.214.1.0 - 132.214.999. server_ip_allowed could be updated to include the following:

    P D 132.214.1.*

    (The "A" is for "Allowed"; the "D" is for "Denied".) And restart the pc_server.

    A table where *circulation* activites can be restricted based on IP-address is the ./xxx50 tab_attr_sub_library, but since the preceding change to server_ip_allowed would prevent *any* kind of GUI access, change to tab_attr_sub_library would seem unnecessary....

    In fact, it would seem that if the abc50 staff User-ID's are removed, the change to server_ip_allowed would also be unnecessary.


    **PATRON ACCESS**

    In regard to patron access, there are two cases:

    1) The patron has an ABC50 z305 local patron record only {a record with "ABC50" as the Z305-SUB-LIBRARY (bytes 13-17 in the z305_rec_key) only}. This means that the patron is allowed to check out and request abc50 items only and once the abc50 items (and the other abc50 tables) are gone, the patron will be unable to do anything in the system and can be removed entirely. If this is true of *ALL* of the abc50 patrons, then the cir-23 (Delete Patron Records) Service with each of the "All" checkboxes checked can be run.

    2) Some of the abc50 patrons have other local patron records, either a z305 in another ADM library or a z305 in the $usr_library {with "ALEPH" as the Z305-SUB-LIBRARY (bytes 13-17 in the z305_rec_key)} in the $usr_library, that is, a *shared* local patron record. In this case cir-77 (Update Patron Records), which is set up to distinguish between these cases, must be run. From the cir-77 Help: "This service is intended for use by libraries that have multiple local library patron records (particularly in a Multi-ADM environment). It facilitates central administration for registering expiration dates, cross-library delinquencies, and preparation for patron deletions."

    **In either case the cir-23 or cir-77 must be run (in abc50) BEFORE the abc50 library is dropped. (This is so the shared $usr_library global patron records, IDs, and addresses for ABC patrons can be properly updated or removed.)**

    Additional Information

    See also Articles:

    000024664 (How to remove an ADM library)
    000024665 {Removing Aleph libraries (and sublibraries)}

    Category: System Management (500)


    • Article last edited: 9/29/2014