Users App
(UXPROD-784)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. ContextI think it is important to consider this in relation to the broader domain modelling. FacultiesThere 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 PointsLocations were included in inventory. I think this was done primarily for two reasons:
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
This suggests that there is a single, centrally maintained list of departments.
I think those are really good questions. They could reveal that, whilst both use the same term, they do not mean the same thing.
I’m not sure I really understand these options. Would it be reasonable to reword them as the following?
I think the crucial questions to answer this question are:
One Definition of DepartmentsIf 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 DepartmentsIf 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 SubsetsIf 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
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 FieldsI 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 ReservesThis would mean that in the short term at least, either
How big a compromise these are depends upon what the desired model turns out to be. SearchingI’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 ] |
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.
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:
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.
|
| Comment by Erin Nettifee [ 16/Dec/19 ] |
|
1. Correct. |
| 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.
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
Pending testing, it appears that Cornell does not need to implement Statistical Codes in the Users application. |