Copy Location Search Should be Able to Search Child Org Units
Bug #1730981 reported by
Rogan Hamby
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
New
|
Wishlist
|
Unassigned | ||
Bug Description
We resolved searching parent org units in bug 1346381 but there are situations where we would want to allow libraries to search child org units. This will probably require YAOUS to let libraries control it.
| Changed in evergreen: | |
| assignee: | nobody → Rogan Hamby (rogan-hamby) |
Revision history for this message
| Rogan Hamby (rogan-hamby) wrote | #1 |
| Changed in evergreen: | |
| assignee: | Rogan Hamby (rogan-hamby) → nobody |
| Changed in evergreen: | |
| assignee: | nobody → Rogan Hamby (rogan-hamby) |
| Changed in evergreen: | |
| assignee: | Rogan Hamby (rogan-hamby) → nobody |
| Changed in evergreen: | |
| importance: | Undecided → Wishlist |
| tags: |
added: orgunitsettings search removed: wishlist |
To post a comment you must log in.
I gave this just a bit of thought today since someone asked me about it. I do think we need YAOUS set for child org units as a parent org may want to search some child shelving locations but not all. For example, a headquarters library that has a book mobile org and a tech services org as children and wants shelving locations for the bookmobile to show up. And it may need to populate up more than one parent level.
So, my thinking currently is a setting for populate parent copy location search and if null it ignores it, if given an integer value it goes that back up the tree to include it's copy locations. One concern I have though is that systems in a consortium could unwitting add their copy locations to consortial search. Thoughts?