Status: Closed (View Workflow)
Problem: Any FOLIO user can log into FOLIO and only a small fraction of those users (library staff) currently have anything they can/should be doing in FOLIO.
- Not an Option: Using the existing Status flag on the user record to control this isn’t an option. The Status flag will be used for other things in FOLIO. For example, when a user graduates, they would be switched to inactive which should mean they could no longer log into FOLIO and they can no longer check out books. This is distinct from another flag we plan to implement on the user record called Patron block which would also disallow checking out books due to fees, fines and other FOLIO logic. Patron block will likely be auto triggered by certain data in FOLIO while Status will be driven by data in the Student Information System.
- Option 1: Allow any user to log in but just ensure that they can’t do anything at all in FOLIO (not even change their own username and password) without additional permissions assigned. Taking this approach is potentially confusing to users who manage to accidentally log in, though. If we are going to do this, SIG would want us to have a configurable landing page that says something like “Oops – you landed in our system. Here are some links to where you might want to go from here” (with links to discovery etc). One advantage to this is that, if someone does eventually build a patron-facing app in FOLIO, nothing additional needs to be done to allow them to log in.
- Option 2: Have a logical permission for “Can log in”. One downside to this approach is that you will have to remember to assign this permission set to every user that needs to log into FOLIO (or put into every permission set you create). That’s probably not a deal-breaker.
- Option 3: Add a data element to the user record for “Can log in” which, if set to N, disallows login. If set to Y, allows login. So, it would work like Status, but be distinct. It would need to be manually set to Y for all people who need to log into FOLIO. If we take this approach, we’d need to make sure the regular user import doesn’t reset this flag all the time. We could handle this by saying that, as long as this field is left blank in the patron import, the system doesn’t alter the setting.