<div dir="ltr"><div dir="ltr">Hi Mike!<div><br></div><div>OP here, aka kmlussier. Thanks for adding your thoughts! My comments are below.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To reiterate the reason we kept the library groups and location groups<br>selector separate from the library (org unit) selector, and also<br>combined them into one UI element: both library and location groups<br>are NOT subordinate to org units, because they can cross hierarchical<br>boundaries, and they are mutually exclusive, because they represent<br>different, competing, non-hierarchical search contexts. Instead their<br>applicability is /dependent/ on the context ("search", yes, but not<br>only search) org, and essentially /replaces/ it in the search.<br>Especially for large installations with many org units, using either<br>of these grouping mechanisms becomes untenable if we try to shove them<br>all into the same dropdown as the libraries, because they would have<br>to be duplicated in many places and would thereby make the long org<br>list even longer and harder to use.</blockquote><div><br></div><div>I can delve into our reasons for displaying the groups in the selector. Most of our copy location groups are really departemental level groups (children's, teen, adults), similar to the department levels that were suggested at one time as possible child org units to branches. However, we didn't want all of the other things that come with creating a new org unit: a new pickup location, a message to send items into transit when items are checked in at the branch, etc. We just wanted the department level for the purposes of searching. </div><div><br></div><div>In the minds of our libraries and patrons, these shelving location groups are "search scopes" in the same way that a branch or a system is a search scope. On the public side, most patrons will not bother to go to the advanced search page to see what's there, but they will easily see there is a way to search the children's collection from the main search page. I get what you're saying about large installations with many org units, but I also know that CW MARS, which is far larger than us, is also interested in seeing these restored to the library selector.</div><div><br></div><div>Out of curiosity, are there other libraries / consortia out there who are using shelving location groups? If you are using them and do not want to see them in the library search selector, it would be good to know. I guess we shouldn't assume that restoring the traditional method is the approach everyone wants to take.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding the main "hide certain orgs" concept from the OP, on<br>balance, it definitely feels to me like a job for custom org trees<br>with a new "purpose" (the one existing purpose being: "opac"),</blockquote><div><br></div><div>To be clear, this isn't really a "new" purpose. The custom org trees always worked in the tpac staff catalog. For this year, NOBLE is prioritizing development for features we previously funded, either individually or as part of a larger development cooperative, that were inadvertently missed as interfaces were replaced. Getting the library search selector in the Angular catalog looking like the one we used in the tpac staff catalog is something our libraries have told us is necessary before they're willing to move to the Angular Catalog.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding the main "hide certain orgs" concept from the OP, on<br>balance, it definitely feels to me like a job for custom org trees<br>with a new "purpose" (the one existing purpose being: "opac"),<br>especially given the variable shape of the tree mentioned up-thread in<br>some cases. While there does exist a way to hide "intermediate" org<br>units today, it requires the interaction of multiple configuration<br>points (opac_visible flags, and the "inherit visibility" library<br>setting(s)), which makes it feel flimsy in comparison to an explicitly<br>defined tree. A single "this is what my staff should see *in this<br>interface*" option seems (1) conceptually simpler, (2) more flexible,<br>and (3) more maintainable.</blockquote><div><br></div><div>I agree that the custom org tree is much more flexible, but we really don't need that flexibility. I'm not sure that I agree that it is conceptually simpler or more maintainable. Although the Angular custom org tree admin interface is a huge improvement over the old dojo one, I find it's much simpler to just uncheck a visibility box when setting up or editing an org unit. The org tree admin is another place you have to remember to go after setting up the org unit to make sure it displays correctly in the catalog. But as I said to Galen, we'll reconsider it.</div><div><br></div><div>Thanks Mike!</div><div>Kathy</div><div> </div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>--</div>Kathy Lussier<div>she/her<br><div>Executive Director</div><div>NOBLE: North of Boston Library Exchange</div><div>Danvers, MA</div><div>978-777-8844 x201</div><div><a href="http://www.noblenet.org" target="_blank">www.noblenet.org</a></div><div><br></div><div><br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 24, 2024 at 12:51 PM Mike Rylander via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
As Andrea mentioned, we've been working on functionality adjacent to<br>
the main topic of this thread for a bit. The pullrequest branch is<br>
attached to the Library Groups LP bug she pointed to, and you can find<br>
it here:<br>
<br>
<a href="https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups" rel="noreferrer" target="_blank">https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups</a><br>
<br>
To reiterate the reason we kept the library groups and location groups<br>
selector separate from the library (org unit) selector, and also<br>
combined them into one UI element: both library and location groups<br>
are NOT subordinate to org units, because they can cross hierarchical<br>
boundaries, and they are mutually exclusive, because they represent<br>
different, competing, non-hierarchical search contexts. Instead their<br>
applicability is /dependent/ on the context ("search", yes, but not<br>
only search) org, and essentially /replaces/ it in the search.<br>
Especially for large installations with many org units, using either<br>
of these grouping mechanisms becomes untenable if we try to shove them<br>
all into the same dropdown as the libraries, because they would have<br>
to be duplicated in many places and would thereby make the long org<br>
list even longer and harder to use.<br>
<br>
Regarding the main "hide certain orgs" concept from the OP, on<br>
balance, it definitely feels to me like a job for custom org trees<br>
with a new "purpose" (the one existing purpose being: "opac"),<br>
especially given the variable shape of the tree mentioned up-thread in<br>
some cases. While there does exist a way to hide "intermediate" org<br>
units today, it requires the interaction of multiple configuration<br>
points (opac_visible flags, and the "inherit visibility" library<br>
setting(s)), which makes it feel flimsy in comparison to an explicitly<br>
defined tree. A single "this is what my staff should see *in this<br>
interface*" option seems (1) conceptually simpler, (2) more flexible,<br>
and (3) more maintainable.<br>
<br>
If we were/are voting, that'd definitely get my vote.<br>
<br>
Thanks!<br>
<br>
--<br>
Mike Rylander<br>
Research and Development Manager<br>
Equinox Open Library Initiative<br>
1-877-OPEN-ILS (673-6457)<br>
work: miker@equinoxOLI.org<br>
personal: <a href="mailto:mrylander@gmail.com" target="_blank">mrylander@gmail.com</a><br>
<a href="https://equinoxOLI.org" rel="noreferrer" target="_blank">https://equinoxOLI.org</a><br>
<br>
On Tue, Jan 23, 2024 at 12:01 PM Andrea Buntz Neiman via<br>
Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
><br>
> Chiming in to note that Equinox recently completed work on these related bugs:<br>
><br>
> <a href="https://bugs.launchpad.net/evergreen/+bug/1949109" rel="noreferrer" target="_blank">https://bugs.launchpad.net/evergreen/+bug/1949109</a> - Add Library Groups to Angular Staff Catalog<br>
> <a href="https://bugs.launchpad.net/evergreen/+bug/1861701" rel="noreferrer" target="_blank">https://bugs.launchpad.net/evergreen/+bug/1861701</a> - Angular staff catalog copy location group filtering support<br>
><br>
> We will be sharing a branch shortly.<br>
><br>
> ABN<br>
><br>
> On Tue, Jan 23, 2024 at 11:39 AM Tina Ji via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>><br>
>><br>
>> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> > #2 introduces new behavior that hasn't been used in previous staff<br>
>> > catalogs. We could not think of a use case where an org unit<br>
>> > should be invisible in the public catalog when performing a<br>
>> > search, but should be visible in the staff catalog search. However,<br>
>> > if there is one, let us know so that we can add an option,<br>
>> > most likely a global flag.<br>
>><br>
>><br>
>> One of our library system does central cataloguing at its headquarter, which is not open to the public. It's OPAC invisible, but needed on the staff catalogue.<br>
>><br>
>><br>
>> ________________________________<br>
>> From: Evergreen-general <<a href="mailto:evergreen-general-bounces@list.evergreen-ils.org" target="_blank">evergreen-general-bounces@list.evergreen-ils.org</a>> on behalf of Terran McCanna via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>><br>
>> Sent: Tuesday, January 23, 2024 7:13 AM<br>
>> To: Evergreen Discussion Group <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>><br>
>> Cc: Terran McCanna <<a href="mailto:tmccanna@georgialibraries.org" target="_blank">tmccanna@georgialibraries.org</a>><br>
>> Subject: Re: [Evergreen-general] Sharing plans for changing library selector in Angular staff catalog<br>
>><br>
>> About disused Org Units - even after a branch closes completely and all of the active materials and patrons have been moved off of it so we don't want it to appear in most dropdown lists, we sometimes still need to run reports on it. It would be nice to have the option in the reporter to include non-staff-visible branches. Maybe that is as simple as adding a new report source in the fieldmapper that can be used instead of the normal Org Unit source when desired?<br>
>><br>
>> On Mon, Jan 22, 2024 at 5:46 PM Galen Charlton via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> > #2 introduces new behavior that hasn't been used in previous staff<br>
>> > catalogs. We could not think of a use case where an org unit<br>
>> > should be invisible in the public catalog when performing a<br>
>> > search, but should be visible in the staff catalog search. However,<br>
>> > if there is one, let us know so that we can add an option,<br>
>> > most likely a global flag.<br>
>><br>
>> I can think of several:<br>
>><br>
>> - Library joining a consortium. Most any migration workflow I can imagine will result in a period of at least a few days, and sometimes longer, where an OU exists and has holdings attached to it but shouldn't be visible in the OPAC, but where staff nonetheless need to be able to do staff-side searches limited to that OU.<br>
>> - Library opening a new branch with an opening day collection. This could lead to an even longer period where the OU exists but is not yet ready to be visible to patrons<br>
>> - An explicitly hidden or resource collection<br>
>><br>
>> Does NOBLE have OUs that are completely disused?<br>
>><br>
>> Regards,<br>
>><br>
>> Galen<br>
>> --<br>
>> Galen Charlton<br>
>> Implementation and IT Manager<br>
>> Equinox Open Library Initiative<br>
>> gmc@equinoxOLI.org<br>
>> <a href="https://www.equinoxOLI.org" rel="noreferrer" target="_blank">https://www.equinoxOLI.org</a><br>
>> phone: 877-OPEN-ILS (673-6457)<br>
>> direct: 770-709-5581<br>
>> _______________________________________________<br>
>> Evergreen-general mailing list<br>
>> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
>><br>
>> This message originated from outside the M365 organisation. Please be careful with links, and don't trust messages you don't recognise.<br>
>> _______________________________________________<br>
>> Evergreen-general mailing list<br>
>> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
><br>
><br>
><br>
> --<br>
> Andrea Buntz Neiman, MLS<br>
> Project Manager for Software Development | Product Specialist<br>
> Equinox Open Library Initiative<br>
> abneiman@equinoxOLI.org<br>
> 1-877-OPEN-ILS (673-6457)<br>
> Direct: 770-709-5583<br>
> <a href="https://www.equinoxOLI.org/" rel="noreferrer" target="_blank">https://www.equinoxOLI.org/</a><br>
> _______________________________________________<br>
> Evergreen-general mailing list<br>
> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
_______________________________________________<br>
Evergreen-general mailing list<br>
<a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
<a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
</blockquote></div>
</div>