Users App (UXPROD-784)

[UXPROD-2147] Users App: Department Field Created: 07/Nov/19  Updated: 16/May/23  Resolved: 15/Oct/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2020
Parent: Users App

Type: New Feature Priority: P3
Reporter: Khalilah Gambrell Assignee: patty.wanninger
Resolution: Done Votes: 0
Labels: cap-mvp, migration-load, po-mvp, q4-2019-spillover, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-1295 Users App: Add phone number type and ... Closed
Defines
is defined by MODUIMP-16 Add Department field to mod-user-import Closed
is defined by UIU-1211 Settings > Users > Department CRUD to... Closed
is defined by UIU-1224 Create/Edit/View User Record | add D... Closed
is defined by UIU-1355 Users App | Add a Departments filter Closed
is defined by UIU-1778 Departments: Create UI permissions fo... Closed
Duplicate
is duplicated by UXPROD-261 Users App: Additional Identifier Fields Closed
Relates
relates to REP-221 Active patrons by stat code Closed
relates to MODUIMP-18 Support ability to create a departmen... Closed
relates to MODUSERS-99 Create New Field: Is Deceased Closed
relates to MODUSERS-158 Create/Edit a Department Closed
relates to UIU-696 New/Edit/Show User Detail Record: Add... Closed
relates to UXPROD-1400 Users App: Implement Affiliation Grou... Closed
relates to UXPROD-850 Migration Tools Open
relates to MODUSERS-200 Delete a department Closed
Requires
is required by UXPROD-2062 Anonymized loans: retain patron custo... Open
is required by UXPROD-2117 Users app: add newly added fields to ... Closed
Epic Link: Users App
Front End Estimate: Large < 10 days
Front End Estimator: Khalilah Gambrell
Front-End Confidence factor: Medium
Back End Estimate: Large < 10 days
Back End Estimator: Khalilah Gambrell
Estimation Notes and Assumptions: Holly did estimates because we needed to get something set for the capacity plan ASAP and no one else was estimating this feature.
Development Team: Spitfire
PO Rank: 106
PO Ranking Note: Even though Users will be making use of custom fields, there are a still few fields where it makes sense to just add them to the data schema.
Rank: BNCF (MVP Feb 2020): R1
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R5
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

Allow libraries to assign a department(s) to a User record.



 Comments   
Comment by Khalilah Gambrell [ 07/Nov/19 ]

patty.wanninger and Cate Boerema, I split Department and External System ID fields into two features because Vega will take one feature and Spitfire will take another feature.

Comment by Marc Johnson [ 13/Dec/19 ]

patty.wanninger Khalilah Gambrell Cate Boerema Kurt Nordstrom Mike Taylor Jakub Skoczen

Hi folks I’ve been asked to contribute my ideas to the department conversation.

I’m not an architect or authority in these areas so these are only my thoughts.

I’ve tried to focus on Khalilah Gambrell’s questions and some specific areas folks mentioned.

If folks would like me to expand upon my thoughts, I’m happy to do so in a follow up comment.

I’ve tried to keep it short, yet it has still meandered. Please do ask if something doesn’t make sense.

Context

I think it is important to consider this in relation to the broader domain modelling.

Faculties

There are ongoing conversations around defining faculties in FOLIO. I think this is mostly going on in the ERM and app interaction groups. I wanted to draw folks attention to this in case there is overlap or value in considering how these might be related.

Locations and Service Points

Locations were included in inventory. I think this was done primarily for two reasons:

  • We wanted strong integrity constraints between items and locations
  • It was expedient to include it in an existing module, as setting up new modules is expensive

The impact of this is that service points were also included in inventory (for similar reasons). That has led to inventory being required for a user to log in to the system, which I’m confident folks recognise as undesirable.

I think the impact of those decisions demonstrates some challenges for FOLIO and I think it means we need to devote more time to domain modelling and the topics of ownership and coupling.

Khalilah’s Questions

Overall, it would have been ideal for both apps to share the same Department field especially if both Users/Course Reserves will be using the same data feed.

This suggests that there is a single, centrally maintained list of departments.

I think we should ask the UM SIG again, if the department feed includes all departments including Academic as one expects to see in a Course Reserves app. And if there is a scenario whereby a library will use Departments in Users but not in Course Reserves and vice versa.

I think those are really good questions. They could reveal that, whilst both use the same term, they do not mean the same thing.

We have three options

  • Build a separate CRUD in Settings > Users as defined by requirements
  • Create a mod-departments module and make it a tenant level setting that we hope Course Reserves will use at some point
  • Wait for Custom Fields

I’m not sure I really understand these options.

Would it be reasonable to reword them as the following?

  • Define departments for users and course reserves separately
  • Define departments once for all of FOLIO
  • Use custom fields for departments

I think the crucial questions to answer this question are:

  • Is there one definition of departments for a whole organisation?
  • If there is, what part of the organisation defines departments?

One Definition of Departments

If there is intended to be one definition, I doubt either users or course reserves owns that decision. That leads me to think that departments are part of a different context to them.

As FOLIO roughly modules contexts with modules (or at least a module should not live in more than context), departments should probably be in a separate module.

Multiple Definitions of Departments

If the list of departments for users and course reserves are different, that suggests that two separate definitions exist and each should be defined within the contexts / modules they belong to.

This would mean that the administration of departments for users and course reserves would need to be done separately.

One Definition with Separate Subsets

If the same person would be designing both lists, or it is based upon a single list, then what we might be trying to do is filter which departments users or course reserves allows from an overall list of departments.

To implement that, we could either

  • Define the central departments list, share that with both users and course reserves, and they each choose which to use
  • Add fields to the central departments list to say whether each department is used within course reserves or users.

The first of these is a cleaner separation of concerns. Both users and course reserves own the decision for which departments they use. And allows for separate folks to have access to making those decisions.

However this could be challenging to implement in FOLIO at the moment, as we don’t yet have a robust way to share definitions between modules.

Adding the fields, would mean that any user who could change departments would be able to change which ones apply to users or course reserves. This might not be how organisations adopting FOLIO work. It also means that we start to subtly connect users and course reserves to each other.

Custom Fields

I think I am missing something. How would custom fields address the need to define departments

It would help me to understand what comes next

Leaving Departments in Course Reserves

This would mean that in the short term at least, either

  • There will need to be two list of departments
  • Users will need to depend upon course reserves

How big a compromise these are depends upon what the desired model turns out to be.

Searching

I’m not sure I understand the concerns around searching.

I imagine it is about searching when the departments are in a separate module to users or course reserves.

I think that only really matters if there is a need to search users or reserves by fields of a department, rather than by a department itself.

Rather than speculate, please could someone help me understand this better.

Comment by Mike Taylor [ 13/Dec/19 ]

I've not been involved in this whole discussion, and no doubt I'm missing a lot of background. But I'll just chip in from the Course Reserves perspective. For that application, we realised that we needed the ability to associate a course with a department, but that we needed very little richness in the notion of department for our purposes.

So given our very tight timescales, rather than wait for the bigger issues to get addressed, we went ahead and implemented a very very simple CRUDable notion of department consisting only of id, name and description (plus the usual metadata about who created and last edited the record, and when). That suffices for us to be able to progress the rest of the Course Reserves work, so from our very narrow perspective the issue is sort of closed. In particular, it means we have nothing that we feel a need to contribute to the broader discussion, provided that whatever notion of department FOLIO eventually ends up with has a name and description.

That said, if and when FOLIO gets around to providing a richer and more generalised notion of department, it would not be too difficult to switch the Course Reserves module to use that instead, if users of CR would find that helpful. So we don't rule it out, but it's not on our To Do list.

Hope that helps.

Comment by Erin Nettifee [ 13/Dec/19 ]

Faculties
There are ongoing conversations around defining faculties in FOLIO. I think this is mostly going on in the ERM and app interaction groups. I wanted to draw folks attention to this in case there is overlap or value in considering how these might be related.

I looked briefly at the Jiras, but don't understand what they are defining as "faculties", but if it's more like a college level administration, I don't think it will have much relevance to the discussion.

I think we should ask the UM SIG again, if the department feed includes all departments including Academic as one expects to see in a Course Reserves app. And if there is a scenario whereby a library will use Departments in Users but not in Course Reserves and vice versa.

There are absolutely these scenarios. I'll try to give a real-world example. Duke has a concept of an "org key" that is pretty much comparable to department, and which shows up in identity management feeds. There's roughly 350 "org keys" for monthly payroll, so you can roughly say that we would have 350 academic and administrative departments. (It's not a total 1-1 match. Some departments might have more than one monthly org key.)

Of that list, you have these kinds of departments:

  1. Academic departments like English and Sociology, which could be used both in Users and in Courses.
  2. Administrative departments like University Housekeeping, which would only be used in Users.
    1. In the example where an administrator is hired to teach a class, they would receive a temporary appointment in that department. So it wouldn't be the case that the administrative department is the owner of the class.

Scenarios for departments that are in Courses, but not in Users, are I think less frequent but still something that would happen.

An institution that has a lot of schools and colleges might have a scenario where the incoming identity information is at the school level, but the courses are at an academic level.

Like I could imagine someplace like Michigan State University (MSU), where they have a School of Packaging (https://www.canr.msu.edu/packaging/). I don't know their specifics, but I could imagine in that case that faculty/staff employed in that school might have a Users department of "School of Packaging" whereas the courses they taught would have course departments like "Packaging Science."

Or someplace that has a Continuing Ed school, where the Users department for faculty/staff is "Continuing Ed" but the Courses department, if they use Reserves, is something like "Lifelong Learning." (https://learnmore.duke.edu/olli)

Comment by Mike Taylor [ 13/Dec/19 ]

Erin Nettifee Are you saying that the same department would be known as "Continuing Ed" in the Users module, but as "Lifelong Learning" in the Course Reserves module?

Comment by Erin Nettifee [ 13/Dec/19 ]

Mike Taylor I think it's a plausible scenario, but wouldn't necessarily have to be the case.

Very common: Dr. Jane Smith is hired to teach in the English department. Her university appointment code is ENGLISH, and her courses are in ENGLISH.

Less common but still possible: Jane Smith is hired by the Department of Continuing Education to teach courses for local seniors in their Lifelong Learning Department. Jane has a university appointment, and the department that hires her is Continuing Education. (Her "organization" in an identity management feed would be something like CONTED.) Users would want to rely on the department in the feed.

For Course Reserves, her students would walk up to a desk and say something like "I'm taking a Lifelong Learning class." Department in the Courses context is both about reporting, but also how students are identifying their courses and how materials are found.

Continuing Ed might have various departments like Lifelong Learning; Talent Identification Programming (classes for gifted kids); Executive Education, etc.

Or for the Michigan State example, Dr. Jane Smith is hired as a new faculty member in the School of Packaging. Her university department code could be something like SCHPACK. Her students would come to the desk and ask for "the textbook for Packaging 201."

Comment by Kelly Drake [ 13/Dec/19 ]

Because of all the scenarios listed by Erin Nettifee above, especially in a small institution - assigning the same department to a prof and a course is especially dicey. Lots of multi-tasking going on.

Comment by Kelly Drake [ 13/Dec/19 ]

Please note also - I've changed the Rank for FLO from "Go-live" to "not needed" - It is needed for courses, but not users. I'm not sure that all the Rankings reflect the needs of the institutions either. Seems they might have been copied when the ticket was split?

Comment by Cate Boerema (Inactive) [ 16/Dec/19 ]

Thanks so much for all your input Marc Johnson, Mike Taylor, Erin Nettifee and Kelly Drake.

Erin Nettifee's comments suggest to me that "Department" for Course reserves is a different concept from "Department" in Users. If others agree, we should probably implement separate department CRUD for the two apps, ideally with slightly different names (e.g. "course department" and "faculty department")

Comment by Mike Taylor [ 16/Dec/19 ]

By all means use an explicit name facultyDepartment for the concept to be added to Users; we would prefer, though, not to change the existing names used in Course Reserves.

Comment by Erin Nettifee [ 16/Dec/19 ]

It should be something like userDepartment in the Users app, so that it can be understood to apply to staff and student users in addition to faculty.

Comment by Mike Taylor [ 16/Dec/19 ]

The departments used in the Course Reserves app are found at /coursereserves/departments, which I guess is pretty explicit.

Comment by Khalilah Gambrell [ 16/Dec/19 ]

Erin Nettifee, I am reviewing what you stated: Sorry I keep updating my comments.

  1. Based on what you stated Users needs to include all departments and Course Reserves a subset.
  2. Users needs departments to support identity matching? Or something else?
  3. And do most universities have one feed that includes Academic and Administrative departments?
Comment by Erin Nettifee [ 16/Dec/19 ]

1. Correct.
2. Identity matching, reporting, and facilitating services. For example, if I know that someone’s department is history, which is on our east campus, I know the library they are probably most comfortable with is the library on that campus and can refer accordingly.
3. Yes. Using Duke as an example: If you are an employee (faculty or staff), you have an associated org key in your identity record that maps to your hiring unit / department, which could be academic or administrative. If you are a student, your identity record will have an associated key that maps to your degree program. If you are a student and staff at the same time you would have both.

Comment by Khalilah Gambrell [ 17/Dec/19 ]

patty.wanninger and Cate Boerema, I think this is my struggle with Departments. Same feed supports both. So if we do separate settings, same feed supports the same thing. Also I guess the other question is this - Does Users need a Departments CRUD? Is it enough to have the data feed populate Department value(s) in a User Record. So I propose - User record's Department field is read-only and can only be updated via data feed IF that is the common use case.

Comment by Erin Nettifee [ 17/Dec/19 ]

Hi Khalilah, suggest taking that proposal to RA. I think you will find people don’t want it to be read only.

Comment by Andrea Loigman [ 17/Dec/19 ]

Data feed is the most common case, but far from the only case.

  • Some smaller institutions might not include this info in their feeds at all, meaning manual input may be only way to capture it.
  • It's fairly common these days to have faculty who have interdisciplinary appointments and grad students working on interdisciplinary issues. I've been at 2 institutions where identity management couldn't/wouldn't control which department is in the feed in these situations. Libraries will need to be able to alter field and lock it in these cases.

Happy to provide specific examples if it'll help.

Comment by Sharon Beltaine [ 02/Sep/20 ]

Cornell: a small group evaluated the options for Cornell with regard to Patron Codes. It appears that the combination of the Department field and Custom fields will provide the solution that Cornell needs. Testing of custom fields and reporting from them can begin with GoldenRod. Testing of Department fields and reporting from them can begin with Honeysuckle. The Cornell Patron Feed will be modified to accommodate the Patron Code reporting needs identified in REP-221 Closed .

Pending testing, it appears that Cornell does not need to implement Statistical Codes in the Users application.

Generated at Fri Feb 09 00:21:31 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.