[Umlaut-general] Institutions vs. Groups

Thu Sep 8 12:00:21 EDT 2011

Thanks, helpful, makes sense.

So Institution may sometimes be determined by having a logged in user, 
and other times by IP address? Cool.

Yeah, with adding institution to SFX, one trick is with SFX request 
caching.  If you request the same URL from Umlaut a second (or 
subsequent) time (in same session!), Umlaut will not start a new request 
for you, but just hook you up with the same "Request" object again. This 
is important both for general performance, and to make sure refreshes to 
get background services hook up with the same request, don't start off a 
new one.

But I don't think the whole URL is used for matching cache, certain 
parameters are considered significant certain ones not. I forget exactly 
where the code is and how it decides, it may be confusing. So anyway, if 
institution is in the URL, you have to make sure that it _is_ deemed 
significant for request caching purposes -- requesting the otherwise 
same url with a different institution, you definitely want to launch a 
new Umlaut request, _not_ hook up with the previous request with a 
different institution or no institution.

As far as "but the tricky part will be determining which institutions 
are in play for a particular session and if SFX controls the URL for the 
session. "

I'm not sure what you mean by "if SFX controls the URL for the 
session".  But in general, I guess you're talking about using both IP 
lookup and user account, and possibly Umlaut URL, to determine 
Institution in play? I'd actually avoid using a Rails session at all for 
this.  Calculate it on for the individual request, perhaps add new 
attributes to the Umlaut Request model to save it for a request (recall 
as above that an Umlaut Request can be re-used accross HTTP requests) -- 
but don't try to save anything in the Rails session, will make things 
much less confusing.  (Of course the current logged in user will be 
saved in Rails session, but that's it).

On 9/8/2011 10:41 AM, Scot Dalton wrote:
> Right, use case.  The basis for this is that we're part of a consortium of libraries with Cooper Union and The New School that have their own SFX instances and we're the main library tech shop for the NYU global network university, with portal campuses (degree granting entities) in several locations around the world.  The consortium members aren't licensed to access our electronic resources remotely, but have access to our physical location and can access our resources from here.  The consortium members have there own web presence, look&  feel, and staff.  The portal campuses currently share our SFX instance (theoretically this could change), and have there own web presence, look&  feel, and staff.  Additionally, in the near future, we hope to bring on board other division of NYU NY that have there own SFX instances, web presences, look&  feel, and staff.  Complicating this a bit is that some users can be associated with multiple consortium members and/or multiple portal camp
>   uses.  We have some business logic that will determine the hierarchy of these affiliations.
>
> We're planning on hosting Umlaut for some consortium members and the portal campuses and would like to maintain one code base/configuration base for all the different groups.
>
> Use cases examples:
> 1. Consortium library user (logged in) at NYU NY location:
> Should by default get the NYU layout, NYU AZ search, and NYU&  consortium library SFX resources (since they have access to both).  Should also be able to access consortium library layout via URL.
>
> 2. Anonymous user at consortium library:
> Should by default get the consortium library layout, consortium library AZ search, and consortium library SFX resources.  Should also be able to access any other library layout via URL.
>
> 3. Portal campus library user (logged in) at NYU NY location:
> Should by default get the NYU NY layout, NYU AZ search, and NYU SFX resources.  Should also be able to access portal campus library layout via URL.
>
> 4. Anonymous user at portal campus:
> Should by default get the portal campus layout, NYU AZ search, and NYU SFX resources.  Should also be able to access any other library layout via URL.
>
> It's straightforward to associate a layout and AZ search (including SFX db info) with an institution.  It's also straightforward to associate and institution with an IP address and for determining layouts/AZ search.  Based on the feedback below, I'll associate user and institutions at the user level and the business logic mentioned above will determine which is the user's primary institution.  Switching the AZ search method per session is a little tricky, but ruby's meta programming aspects make it a easier to manage.
>
> So the "primary institution" will determine layout and AZ search and the hierarchy will be URL, IP, user, default.   Services will display based on the primary institution, institutions affiliated by IP, and user institutions.
>
> The final little piece that I can think of, is that SFX urls may need an institution.  It's easy to add an institution to a SFX url, but the tricky part will be determining which institutions are in play for a particular session and if SFX controls the URL for the session.  I'll investigate how this would work.  Of course, if no institution is specified, it would just check all SFX urls.
>
> Let me know if you have any questions or concerns.
>
> Thanks,
> Scot
>
>
> On Sep 7, 2011, at Sep 7, 6:03 PM, Jonathan Rochkind wrote:
>
>> Oh, I'd also be really interested in understanding your use case that you are actually writing this for: I don't think you've actually told us yet, and I've got some guesses, but don't really know.
>>
>> On 9/7/2011 4:56 PM, Jonathan Rochkind wrote:
>>> I think you should keep it as simple as you think you can to do what you want.
>>>
>>> It looks to me like your #2 includes the Institutions from #1, _plus_ something more.  So I'd go with #1, which is simpler.
>>>
>>> Also, you mention "since there is no longer an institutions table" -- I can't remember if I took that out or it got taken out before even Umlaut 2, but either way, if you think your feature can get done cleaner/neater/more-maintainable/more-performant with an Institutions table, then you can add one!
>>>
>>> What's a "resolve service" in your list of things that may vary by Institution?
>>>
>>> Also, please document everything well once yu've done it -- I dont mean in code comments, I mean some high level documentation about how this feature is intended to be used, and how to use it.
>>>
>>> Also, I'm _still_ going to try to do a major refactor of Umlaut to Rails3 and ruby 1.9.x in the next few months, hopefully this additional functionality will transfer well, but I'll need to understand it to try and migrate it, thus the request for docs! (Alternately, leave it un-migrated and make you migrate it. :) ).
>>>
>>> Also, heads up, at some point in the near future, at some point before I start on my refactor, I want to move Umlaut from rubyforge/svn to github/git.  Scot, do you have any feelings pro or con about git or github? Used git before?  As far as I'm concerned, Umlaut can move to github at any time, although I won't do it without coordinating with you, and wont' do it myself until I get to it.  But it could move sooner if someone wanted to move it and update documentation (including installation documentation etc, since at the moment Umlaut's still installed with a source checkout).
>>>
>>>
>>> On 9/7/2011 4:33 PM, Scot Dalton wrote:
>>>> Hi all,
>>>> I'm well on my way with building out Umlaut to handle different groups of users.  One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc.  I'm considering two approaches, detailed below, that I'd like some feedback on.
>>>>
>>>> 1.) Institutions
>>>> Institutions would have information about IP ranges, layouts, search methods, resolve services, etc.  Basically any information regarding a set of configurations for display, searching and link resolution.
>>>> Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods).
>>>>
>>>> Pros: very straightforward to implement
>>>> Cons: not very extensible; stores both display information and core services/functionality in the same place
>>>>
>>>> 2.) Groups
>>>> Groups have many and belong to users.  Groups store information about layouts and IP ranges for display purposes.  Users would have a primary group to determine the layouts used.  A group would also have an institution associated with it.  Institutions would contain information about search methods and resolution services.  Groups would tie users to institutions and allow user to get multiple services.
>>>>
>>>> Pros: separate out display data from services and search functionality; extensible
>>>> Cons: more work; probably over engineered
>>>>
>>>> Let me know what you think of these two options.  I'll probably start working on it tomorrow.  I'm really not sold one way or the other, so any advice would be appreciated.
>>>>
>>>> Thanks,
>>>> Scot
>>>>
>>>> -- 
>>>> Scot Dalton
>>>> Phone:  (212) 998-2674
>>>> Web Services
>>>> Division of Libraries
>>>> New York University
>>>>
>>>> _______________________________________________
>>>> Umlaut-general mailing list
>>>> Umlaut-general at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/umlaut-general
>>> _______________________________________________
>>> Umlaut-general mailing list
>>> Umlaut-general at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/umlaut-general
>> _______________________________________________
>> Umlaut-general mailing list
>> Umlaut-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/umlaut-general
>
> --
> Scot Dalton
> Phone:  (212) 998-2674
> Web Services
> Division of Libraries
> New York University
>
> _______________________________________________
> Umlaut-general mailing list
> Umlaut-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/umlaut-general