Comment 8 for bug 925776

We are on 2.1 and seeing the same behavior as reported on 2.0.

Beth

On Wed, May 23, 2012 at 4:46 AM, Ben Shum <email address hidden> wrote:

> Going back to James' original bug report, I think we can actually
> confirm that while we were still on 2.0, the located URI's behaved
> strangely for us. For whatever reason, the subfield 9 acted oddly when
> used at the library level vs. the system level. In our system, we have
> a three tier structure (CONS, SYS, BR) and subfield 9 entries at BR
> didn't behave as expected to restrict to only that BR for display while
> subfield 9 entries at SYS did; as far as restricting view of said
> located URIs.
>
> I think this behavior began to change in 2.1+ to match expectations but
> whatever fixes there were never backported fully to 2.0. And since we
> had altered all our located URI's anyways, we didn't get to figuring out
> the actual problem itself.
>
> Will try looking up more details when I get the chance (though 2.0 is
> dead to me!)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/925776
>
> Title:
> located URIs appear in staff client OPAC searches regardless of $9's
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> EG 2.0.10
> Postgres 8.4
> Ubuntu Lucid
>
> The located URIs seem to appear (as greyed out records) regardless of
> scoping within the staff client OPAC (but not the public OPAC).
>
> I can't really think of a use case for this -- if I'm searching with
> my OPAC set to BR1 and "This Branch", I don't want to see 856s with a
> $9 BR2 under that circumstance -- I'd scope out if I wanted to see
> them.
>
> ~James
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/925776/+subscriptions
>