Copy location search does not populate at all org unit levels

[Rogan Hamby]

On the advanced search page if you click on a branch level org unit (depth 2) the copy location search correctly populates. If you click on a system (1) or consortium (0) with assigned copy locations it does not populate.

[Bill Erickson (berick)]

Hi Rogan, this is actually intentional and consistent w/ the JSPAC. The feature was designed to only allow copy location searching when the search org unit type has the "can have volumes" flag set to true. The concern here is the some consortia have altogether thousands of copy locations, many of which have the same name.

We could solve the naming problem by prefixing the copy location with the branch name (assuming that's user friendly), but fetching 5k+ copy locations via JavaScript then displaying a multi-select list of that size would be slow and difficult to use.

I could imagine having a setting to turn off this safety valve for consortia that don't have such large numbers of locations, but we would still need to provide a way to differentiate the names.

[Rogan Hamby (rogan-hamby)]

In our scenario we are all systems with locations owned by our systems and some systems would like to create system level copy locations with few branch level copy locations so the list population length isn't an issue for us. It wouldn't be any longer than a given branch's anyway.

So, to make this work and work for other kinds of setups we might need a YAOUS that defines a depth.

[Mike Rylander (mrylander)]

Rogan,

When searching at a system, would you want the locations for both the system and any branches to display, or only the system level ones? Saying "only the system locations" would simplify the solution, FWIW. :)

[Rogan Hamby (rogan-hamby)]

Well, I'm glad to be able to say that the honest answer would also be only
system locations. :)

On Wed, Apr 22, 2015 at 10:09 AM, Mike Rylander <email address hidden> wrote:

> Rogan,
>
> When searching at a system, would you want the locations for both the
> system and any branches to display, or only the system level ones?
> Saying "only the system locations" would simplify the solution, FWIW. :)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1346381
>
> Title:
> Copy location search does not populate at all org unit levels
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> On the advanced search page if you click on a branch level org unit
> (depth 2) the copy location search correctly populates. If you click
> on a system (1) or consortium (0) with assigned copy locations it does
> not populate.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1346381/+subscriptions
>

[Mike Rylander (mrylander)]

As it turns out, it's a six-of-one situation regarding the solution complexity I mentioned above. I present the following branch to allow display of System and above copy locations, while not falling prey to the HUGE list of Branch locations problem:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1346381-show_locations-wherever-they-exist

[Rogan Hamby (rogan-hamby)]

Tested over the weekend and it went fine. I need to do a signoff now.

On Wed, Apr 22, 2015 at 6:01 PM, Mike Rylander <email address hidden> wrote:

> As it turns out, it's a six-of-one situation regarding the solution
> complexity I mentioned above. I present the following branch to allow
> display of System and above copy locations, while not falling prey to
> the HUGE list of Branch locations problem:
>
> http://git.evergreen-
>
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1346381
> -show_locations-wherever-they-exist
>
> ** Tags added: pullrequest
>
> ** Changed in: evergreen
> Milestone: None => 2.next
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1346381
>
> Title:
> Copy location search does not populate at all org unit levels
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> On the advanced search page if you click on a branch level org unit
> (depth 2) the copy location search correctly populates. If you click
> on a system (1) or consortium (0) with assigned copy locations it does
> not populate.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1346381/+subscriptions
>

[Kathy Lussier (klussier)]

Just adding a comment that, for future development, we would like to see an option for displaying copy locations belonging to child branches. However, I don't think it should prevent this code from going in. I'll file a follow-up wishlist bug since we do have sites where the branch option wouldn't result in a huge list.

[Kathy Lussier (klussier)]

I just tested this on a clean master install with Concerto data, but I came across a problem. When I change the scope of the search to SYS1, I see three copy locations listed: New Arrivals, Reference, and Stacks. However, the Concerto data includes several other OPAC-visible copy locations owned by SYS1 that don't display, including Children's Fiction, Fiction, Juvenile Non-Fiction, Non-Fiction, Special Collections and Young Adult Fiction. I would have expected all of those copy locations to appear in the filter as well.

[Kathy Lussier (klussier)]

I took another look at this branch today because I've received a few questions recently about why the copy location filter doesn't display when the scope is set at the system. My test results are the same as they were a year ago, but I have one more data point to add.

When I select a system-level org unit, the only copy locations that display in the dropdown are the ones owned by the consortium. The ones that don't display are the ones owned by the System.

[Rogan Hamby (rogan-hamby)]

Kathy,

If you feel bored and want to test this should address the issue:

user/rogan/lp1346381_copy_location_search

It's basically the same patch as Mike's but the issue behind the problem you saw was that the current org wasn't getting added to the display_orgs array because that was in the child org population. This patch removes the requirement that the org being displayed can hold volumes and by default populates the shelving location search with shelving locations of itself and all orgs above it.

What this doesn't do is address the concern you had about populating child org units in some situations. Because that is situational I'm not sure there is is a universal means for determining when that should be and it may require YAOUS. Thoughts?

[Kathy Lussier (klussier)]

Thanks Rogan! It works for me. Merged to master for inclusion in 3.1