Ability to suppress transits between certain org units

[Dan Wells]

This feature has been brought up in a number of different contexts, so this bug will hopefully serve as a place to flesh out some ideas of how best to meet the existing needs.

Implementation work is currently in progress here:
http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=shortlog;h=refs/heads/suppress_transits

I'll be posting some feedback below for my institution as soon as possible, but I didn't want to leave this completely hanging, and hopefully others will chime in.

[Thomas Berezansky (tsbere)]

In the interest of documentation:

As of this writing, the implementation mentioned above covers cases where an org unit and all children of it should be considered a common endpoint for transit purposes, but with the ability to limit that to non-hold transits or hold transits only where applicable.

That is, any transit that would end at an org unit within the suppression range would either be completed (if from outside the range) or never even started (if from within the range).

It does not offer automatic configuration of this based on depth in the org tree, but rather requires one or two settings to be set at each org unit you wish to use the feature for. This allows it to be more flexible with complex options.

It can also be overridden at any level of the tree by applying the setting there.

For an example, assuming the following org tree:

Consortium
-System A
--Library 1
---Department 1
---Department 2
--Library 2
---Department 3
---Department 4
-System B
--Library 3
---Department 5
---Department 6
---Bookmobile 1
--Library 4
---Department 7
---Department 8
---Sub-library 1
----Department 9
----Department 10

System A's libraries are actually both in the same building but split for policy reasons, and thus does not want re-shelving transits to occur. Thus, "Suppress Non-Hold Transits" is enabled for System A. Transits for holds will still be generated, to direct them to the correct hold shelf.

Each of the two libraries in System A has only one hold shelf, however, shared by all departments within. So applying "Suppress Hold Transits" at Library 1 and Library 2 will prevent holds from generating transits between departments and the main libraries, but holds will still generate transits between the two libraries.

System B's libraries are two different buildings, so System B has no settings applied at it, as transits should happen between the libraries.

Library 3 has one hold shelf and wants re-shelving to happen without transits, so both settings are applied at it. Thus, Library 3 will not generate any transits within itself. However, Library 3 has a bookmobile, and items should transit in and out of it. So both settings are applied to the bookmobile with the value set to "false" to disable transit suppression for the bookmobile.

Library 4 has the same basic setup as Library 3, but has a specialist sub-library within it, with hours differing from the main library. Due to this Library 4 wants items to transit to and from the sub library, but not within it. By setting both settings at the sub-library it becomes a transit suppression group of its own, suppressing transits within itself but not between it and Library 4.

Thus, from a settings point of view, the above can be set as follows, with T representing non-hold transits, H representing hold transits, + representing a true value, and - representing a false value:

Consortium
-System A (T+)
--Library 1 (H+)
---Department 1
---Department 2
--Library 2 (H+)
---Department 3
---Department 4
-System B
--Library 3 (T+) (H+)
---Department 5
---Department 6
---Bookmobile 1 (T-) (H-)
--Library 4 (T+) (H+)
---Department 7
---Department 8
---Sub-library 1 (T+) (T+)
----Department 9
----Depar...

[Dan Wells (dbw2)]

Thanks, this documentation is very helpful.

Here is our current modest hierarchy:

HEKMAN
--GENERAL
----CAYVAN
----RECREAD
----REFERENCE
--GOVDOCS
--ARCHIVES
--MEETER
--MRC

This arrangement is for search scoping reasons and policy reasons. For actual desking reasons, we would like to not have transits among GENERAL, RECREAD, REFERENCE, GOVDOCS, and MRC.

So, given the current code, we could set it as (ignoring holds):

HEKMAN (T+)
--GENERAL
----CAYVAN (T-)
----RECREAD
----REFERENCE
--GOVDOCS
--ARCHIVES (T-)
--MEETER (T-)
--MRC

Does that look right? So the code looks workable for us, and I think our case is toward the convoluted end of the spectrum. Nice work.

That said, there are some issues. The first thing that bothers me is that some results are surprising (non-intuitive). For instance, had I set CAYVAN to (T+), the end result for this tree would be identical (I think). Any time opposite settings have the same result is an opportunity for confusion. There may be some way to change the setting wording (name or description) to help here, but I am having trouble coming up with something better than what is there. The idea is something like 'True values establish a new transit suppression group, while false values opt-out of any group set higher up'.

The second thing that bothers me a bit is that this feature already has a small audience, yet doesn't cover certain cases. For instance, it is well possible that MRC and MEETER will end up sharing a circ desk in our library (for convenience reasons, as they are physically close, but collection-ally very different). Without changing our tree, I don't think multiple sets of sibling nodes can be transit suppression groups (e.g. GENERAL/GOVDOCS as one group and MEETER/MRC as another).

So, I'd like to at least discuss some different possible methods to address these concerns. One idea which borrows a bit from the work you have done here would be to create a setting named 'Shared Desk Name' (and another setting for Holds, as in the proposed code). Then the logic would be "any org_units with the same 'Shared Desk Name' do not transit". In our tree, we might decide on a shared desk name of 'MAIN', then assign that value as follows:

HEKMAN
--GENERAL (MAIN)
----CAYVAN
----RECREAD (MAIN)
----REFERENCE (MAIN)
--GOVDOCS (MAIN)
--ARCHIVES
--MEETER
--MRC (MAIN)

This would allow for any arbitrary groups, and is (in my opinion) at least somewhat more intuitive (easier to describe, less chance for surprise). One clear drawback is the need to coordinate these values, but at least that is a policy matter more than a technical limitation. To help alleviate that issue, we might instead do something like 'Shared Desk OU', then have secondary OUs reference a shared primary OU, something like:

HEKMAN
--GENERAL
----CAYVAN
----RECREAD (GENERAL)
----REFERENCE (GENERAL)
--GOVDOCS (GENERAL)
--ARCHIVES
--MEETER
--MRC (GENERAL)

Again, the logic would be about the same, "any org_units with the same 'Shared Desk OU' do not transit, but with an OU defaulting to itself for comparison purposes".

In either case, it is a simple matter to meet the sibling need, e.g.:

HEKMAN
--GENERAL
----CAYVAN
----RECREAD (GE...

[Thomas Berezansky (tsbere)]

I decided to switch my branch above to a mixture of my original and your "Named Group" variant.

I left inheritance of the setting in play (your methods seem to imply no inheriting).

Instead of "both use the same setting" (which I broke with a last minute untested change in the previous version. Ooops.) I changed to "both have the same group name" but allowing for an empty group name to be the "off" flag.

Using T: and H: as the setting indicators, to get the system I previously described I would go with settings similar to the following:

Consortium
-System A (T:SYSA)
--Library 1 (H:LIB1)
---Department 1
---Department 2
--Library 2 (H:LIB2)
---Department 3
---Department 4
-System B
--Library 3 (T:LIB3) (H:LIB3)
---Department 5
---Department 6
---Bookmobile 1 (T:) (H:)
--Library 4 (T:LIB4) (H:LIB4)
---Department 7
---Department 8
---Sub-library 1 (T:SL1) (H:SL1)
----Department 9
----Department 10

This still leaves the catch of "a single OU with a unique group name will act as though it was set with the empty string", but at least you get the benefit of saying "What other OUs are in this group? None? Oh, that must be why it isn't doing anything."

From a configuration point of view it is pretty much the same amount of work for when you are only suppressing entire tree segments within themselves.

Your example with a "MAIN" group would need one adjustment, an empty setting on CAYVAN:

HEKMAN
--GENERAL (MAIN)
----CAYVAN ()
----RECREAD (MAIN)
----REFERENCE (MAIN)
--GOVDOCS (MAIN)
--ARCHIVES
--MEETER
--MRC (MAIN)

OR, could be done as so:

HEKMAN (MAIN)
--GENERAL
----CAYVAN ()
----RECREAD
----REFERENCE
--GOVDOCS
--ARCHIVES ()
--MEETER ()
--MRC

Splitting MEETER and MRC together off of that:

HEKMAN (MAIN)
--GENERAL
----CAYVAN ()
----RECREAD
----REFERENCE
--GOVDOCS
--ARCHIVES ()
--MEETER (MEETER)
--MRC (MEETER)

Do you think this will work for you?

[Dan Wells (dbw2)]

This hybrid plan works for me. I'd always welcome a third perspective, but I'm comfortable getting this into master, pending actual testing. If it backports cleanly to 2.0, I can run some live tests today. If not, it may be a week or two before I get time to test this thoroughly.

Thanks!

[Dan Wells (dbw2)]

I made some minor adaptations to this code and have tested and deployed it into our 2.0 environment. We've only enabled the non-holds portions, and so far, no problems, and considerably fewer turtles. I'll try to work out some holds testing within the next day or two.

[Dan Wells (dbw2)]

I've now done some holds testing, and so far, so good. I'm assigning myself and will commit to master assuming it passes a fresh-eyes test tomorrow or (more likely) Monday.

[Thomas Berezansky (tsbere)]

*whips up an upgrade script and pushes it*

Was holding off in case there were more comments.

[Dan Wells (dbw2)]

Pushed to master. Thanks again, Thomas!