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

    One location shows wrong "top" library to select in Basic Search page

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

    Description:
    We just had the v18 upgrade and the following happens in our WebOPAC (for XYZ College only):

    When they connect to the Web OPAC, they see they retrieve the correct HTML extensions (i.e. "-jj", based on tab_base.eng). They, for example, see the correct logo for their school.

    However, they see the wrong base at the top of base-list-include-abc01 (which is the dropdown to select a library/base to search from). They see the union catalog option instead of their local catalog. If they manually select their catalog from the base-list, they see their own base as the default option.

    I checked all their IP profiles thinking that they point to the wrong base. They are pointing to the correct base (XYZ).

    The other puzzling this is that this is working fine on our Test server, and I compared all the HTML files that are involved in the basic search page for XYZ, and they are the same.

    Any idea what I could be missing?

    Resolution:
    The "<select name=local_base>" line in base-list-include-abc01 causes a particular base to be positioned on in the dropdown. If it is not positioned on XYZ, then local_base must not be XYZ.

    If you are seeing the correct HTML extensions, for example, the correct logo for their school, then it must be that it is locating the correct z61 profile (with z61_base = XYZ).

    I suggest that you check the entry produced in the www_server log for this transaction. Does the "request" have &local_base=xyz? Does the "Header: Referer" have &local_base=xyz?

    Compare the www_server log entry for one of the other colleges -- which does not have the problem -- to the log entry for XYZ.

    Also, compare the www_server log entry for XYZ on the Test server (where you have said that it works) to that on Prod.

    [From site:]
    We fixed this problem by correcting the WebOPAC URL they were using.


    • Article last edited: 10/8/2013