[Evergreen-general] Sharing plans for changing library selector in Angular staff catalog

[Lussier, Kathy]

Hi all,

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.

[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.


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.

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:
[image: image.png]

In the old tpac staff catalog where we use the custom org tree, the system
level shows:
[image: image.png]

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.

[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.
> [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.


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.

[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.


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.

[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.


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.

Thanks for thinking through our options!

Kathy

--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org




On Tue, Jan 23, 2024 at 10:13 AM Galen Charlton <gmc at equinoxoli.org> wrote:

> Hi,
>
> On Mon, Jan 22, 2024 at 5:57 PM Lussier, Kathy <klussier at noblenet.org>
> wrote:
> > It sounds like an option is in order then, and I'm now wondering
> > if a global flag is appropriate or something that allows us to
> > determine staff catalog visibility on an OU by OU basis.
>
> Various options I see are.
>
> [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.
> [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.
> [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.
> [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.
> [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.
>
> As you can see, there's a wide range of effort among these options - and
> semantics.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Implementation and IT Manager
> Equinox Open Library Initiative
> gmc at equinoxOLI.org
> https://www.equinoxOLI.org
> phone: 877-OPEN-ILS (673-6457)
> direct: 770-709-5581
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20240124/a78e227f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 18731 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20240124/a78e227f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21855 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20240124/a78e227f/attachment-0003.png>