<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>This is a great discussion. Thanks for the feedback on this project. Unfortunately, I was away from email yesterday and am just catching up with these suggestions. I'll try to respond in the order that the messages were sent.</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">[1] As Jason Stephenson suggested, adding a staff_visible column to actor.org_unit. However, if this is intended to have similar semantics to the opac_visible column - i.e., to suppress results from the staff catalog _search results_ additional work would be needed for the search engine.</blockquote><div><br></div><div>This is a good point and not something we had thought about. I may have assumed the same behavior occurred with the custom org tree. Currently, we suppress the view of the system level for most of our libraries using opac visibility, with the corresponding "Org Units Do Not Inherit Visibility" flag enabled, in the public catalog, but we suppress it in the tpac staff catalog using the custom org tree, as you suggest doing in #4. I just did searches in both to see if I could figure out what the real-world impact is using one over the other. </div><div><br></div><div>In the public catalog where we use OPAC visibility, on the record page, I don't see the hidden system level in the holdings information. See below:</div><div><img src="cid:ii_lrs9mc090" alt="image.png" width="493" height="180" style="margin-right:0px"><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><div>In the old tpac staff catalog where we use the custom org tree, the system level shows:</div><div><img src="cid:ii_lrs9s9z91" alt="image.png" width="562" height="200"><br></div><div><br></div><div>I'm guessing this difference in display is because the custom org tree isn't touching the search? I'll have to run this question by my team here. I have a vague memory that, when the custom org tree development was initially done, we were unhappy that org units removed from the tree displayed in the bib record. This may give us an opportunity to fix something that never exactly work the way we wanted, but I also may be misremembering. </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">[2] Adding a "deleted" column to actor.org_unit to signify that the OU no longer exists. Logical deletion would allow certain types of information to be retained for historical reporting, but would require touching (at minimum) all of the org unit selectors.<br>[3] Adding an "active" column to actor.org_unit. This would be intentionally softer than a "deleted" column, with the idea being that if an OU needs to be deleted, to go through the trouble of fully deleting it from the database. This option would also require touching all of the org unit selectors.</blockquote><div><br></div><div>I love both of these ideas for disused OU's, and would support seeing this work done so that we could remove those OU's from all selectors.. However, we also have what we consider to be the far greater issue of removing the system-level OUs from the search selector. Since the solution to that issue would also result in our ability to remove disused OU's from the search selector, I think we'll need to contain our project to this one selector.</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">[4] If the concern is more about the visibility of the org unit in the _catalog search form selector_, extending the custom OU tree mechanism. Probably less effort.</blockquote><div><br></div><div>I had been  thinking the custom org tree, which provides so much more flexibility for re-ordering org units than we need for this particular project, was too big of a tool for dealing with simple visibility issues, but, as I said above, we'll reconsider this decision.</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">[5] Adding a library setting (tied to the workstation) to list OUs that should not be included in the selector. Also less effort, and might offer some nice flexibility  - i.e., somebody at a branch just sees the active OUs on the selector, while somebody at a central tech services office might see everything.</blockquote><div><br></div><div>We don't need that level of flexibility. There are lots of reasons we want everyone working with the same set of org units in a search selector. One less issue to troubleshoot if org units suddenly disappear is one of them.</div><div><br></div><div>Thanks for thinking through our options!</div><div><br></div><div>Kathy</div><div><br></div><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 Tue, Jan 23, 2024 at 10:13 AM Galen Charlton <<a href="mailto:gmc@equinoxoli.org" target="_blank">gmc@equinoxoli.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"><div dir="ltr"><div>Hi,<br><br>On Mon, Jan 22, 2024 at 5:57 PM Lussier, Kathy <<a href="mailto:klussier@noblenet.org" target="_blank">klussier@noblenet.org</a>> wrote:<br><div>> It sounds like an option is in order then, and I'm now wondering</div><div>> if a global flag is appropriate or something that allows us to</div><div>> determine staff catalog visibility on an OU by OU basis.</div></div><div><br></div><div>Various options I see are.<br></div><div><br></div><div>[1] As Jason Stephenson suggested, adding a staff_visible column to actor.org_unit. However, if this is intended to have similar semantics to the opac_visible column - i.e., to suppress results from the staff catalog _search results_ additional work would be needed for the search engine.</div><div>[2] Adding a "deleted" column to actor.org_unit to signify that the OU no longer exists. Logical deletion would allow certain types of information to be retained for historical reporting, but would require touching (at minimum) all of the org unit selectors.</div><div>[3] Adding an "active" column to actor.org_unit. This would be intentionally softer than a "deleted" column, with the idea being that if an OU needs to be deleted, to go through the trouble of fully deleting it from the database. This option would also require touching all of the org unit selectors.</div><div>[4] If the concern is more about the visibility of the org unit in the _catalog search form selector_, extending the custom OU tree mechanism. Probably less effort.</div><div>[5] Adding a library setting (tied to the workstation) to list OUs that should not be included in the selector. Also less effort, and might offer some nice flexibility  - i.e., somebody at a branch just sees the active OUs on the selector, while somebody at a central tech services office might see everything.<br></div><div><br></div><div>As you can see, there's a wide range of effort among these options - and semantics.<br></div><div><br></div><div>Regards,</div><div><br></div><div>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" target="_blank">https://www.equinoxOLI.org</a><br>phone: 877-OPEN-ILS (673-6457)<br>direct: 770-709-5581</div></div>
</blockquote></div></div>