Courses should not be associated with terms from other orgs (except ancestors)

[Beth Willis]

In Course Reserves, users can manage academic terms from the "Terms" tab on the Course List page.  Currently, the term display defaults to the Consortium location.  Users must select the "Descendants" checkbox to see term data for subordinate locations.  In our consortium, course reserves are managed at the system level and data is not shared among systems.  So it would be preferable for this display to default to the user's working location.

Additionally, users should not have access to terms owned by different working locations.  While it is not possible to edit a term owned by a different working location, but it is possible to associate a course with a term owned by a different working location.

Other consortia may manage course reserves differently, so some discussion may be in order.

EG 3-6-0

[Jeff Davis (jdavis-sitka)]

On my 3.7 beta test server, the Terms tab defaults to the working location. So I think that issue has been resolved in 3.7.

However, I can confirm that it's possible in 3.7 to link a course to a term belonging to another library. This makes sense within multibranch systems, but should not be possible between otherwise unrelated libraries (for example, BR1 should not be able to use terms belonging to SYS2). I think it should only be possible to use a term that belongs to the course's owning_lib or one of its ancestors.

[Jane Sandberg (sandbergja)]

I agree with Jeff, the first part is resolved in 3.7. I will be working on the second part on behalf of the BC Libraries Cooperative.

[Jane Sandberg (sandbergja)]

Here is a branch for that second part (only allow users to associate terms that make sense for the given course): user/sandbergja/lp1906058_course_term_mapping

Here is a link:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1906058_course_term_mapping

Here are the testing notes from the commit message:

1. Create many courses and course terms and many different OUs.
2. On the course list, click "Terms taught". Associate some courses and course terms. Make sure that you aren't able to associate your course with any course terms that would not be reasonable for the course's library.
3. Edit a course, and choose the Course terms tab. Continue to associate courses and terms, and make sure the mappings are reasonable.

[Beth Willis (willis-a)]

EG 3-6-4

Jane's patch works as indicated. I can confirm that the course term map only displays terms owned by relevant libraries and that it is no longer possible to associate a course with a term owned by an unrelated library.

However, the org unit selector on the Term tab still includes all org units and allows the user to display terms owned by unrelated libraries. Users also can select and attempt to edit terms owned by unrelated libraries. Additionally, if a user attempts to edit a term owned by an unrelated library, a toast displays indicating that the update succeeded. This is confusing.

I am not signing off because of the second issue. If I should open a new bug for this, I am happy to do so.

[Jane Sandberg (sandbergja)]

Thanks for your testing, Beth! If I remember correctly, the org unit selector on the terms tab should only show orgs where the user has the MANAGE_RESERVES permission. Were you testing on a user who has MANAGE_RESERVES at the consortium level?

[Beth Willis (willis-a)]

No, the MANAGE_RESERVES permission is not set at the consortium level. I see this when the permission is set at the branch level. I should has specified this.

[Jane Sandberg (sandbergja)]

That's good to know -- thanks, Beth. I think this would work best as a separate bug. Could you please open a new one?

[Beth Willis (willis-a)]

I have opened a new bug (https://bugs.launchpad.net/evergreen/+bug/1939903) on the issue related to the org unit selector noted in comment #4. So, I can confirm that I have tested this code and consent to signing off on it with my name, Beth Willis and my email address, <email address hidden>.

[Galen Charlton (gmc)]

Pushed on down to rel_3_6. Thanks, Jane and Beth!