2017-07-12 User Management Meeting Notes

• The main points can be found in this google document: https://docs.google.com/document/d/1wZw7C9nTXpdGm7Y5w0GBrb813tlZsUJwO4HRsOILFjs/edit#heading=h.vhshf6kabdr6

Decisions and tasks to investigate

• The externalSystemId should be used for checking existing users and as match point for updating users.
• Test what happens with addresses on user update if created an additional address in FOLIO - addresses created within FOLIO shouldn't be deleted unless something is explicitly sent via the update (a blank value? delete flag?).
• Test and document how an address created in FOLIO can be deleted.
• Similar to addresses, it would be nice if data added within FOLIO was ignored/left in tact unless something is explicitly sent to remove/update it. This should also be tested and documented.
• We found that the FOLIO labels match with the User Metadata document's fields but the API fields do not (id = FOLIO ID, username = User ID). This will be discussed with the developers.
• The code should be optimized for large amount of records. Also an id should not have to be provided when creating a new user.
• Instead of Node we could have written the script in e.g. Python or Perl. But the purpose of the script is just a proof-of-concept and probably most institutions are going to want to write their own scripts. The current script is probably fine for that purpose.
  • Most institutions are going to want to write their own scripts anyway because they are doing idiosyncratic things
  • Many institutions will actually have their scripts first pull a complete list of users out of the ILS to compare with the list coming from the SIS. This is done so they can find out who has dropped from the SIS so they can update the ILS to indicate that those people should be expired/inactivated/deleted.
  • User deletion is a complex issue we will need to think through
• Also discussed the notion of protecting data that has been added in FOLIO from overwrite/deletion by import
  • Again reached the conclusion that we could handle this with an exceptions file outside of FOLIO that is referenced by the FOLIO import script (script would look for exceptions and apply them to the data before pushing data into FOLIO)
  • This is a short-term solution. Ultimatly, we'd like to have functionality within FOLIO handle this
• Discussed departmental affiliation
  • There is no field for this in FOLIO at the moment
  • However, it sounds like this is primarily used for statistical analysis and reporting. If that's the case, we would just map departments to the statistical groups which are planned (need to follow up on that to get those going - probably a cross-SIG discussion with RA)
  • Are there other uses for departmental affiliation aside from statistics? Special privileges were mentioned... Let's hold off on adding this until we have some concrete use cases.
• Tod suggested we look at the eduPerson object class specification for user field inspiration: https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-200806.html