Hi James, > why you'd store the 'sticky profile' information into a separate table
A couple of reasons. The most important reason is that user selection of a profile isn’t about what actual profile they get or got, it’s about what they’d prefer. It’s one of potentially multiple (in MyUW, actually multiple) ProfileMappers applying different considerations to determine what profile a user actually gets at runtime. The user desire needs to be stored and faithfully re-considered on subsequent profile mapping chains, but it isn’t necessarily controlling. So it’s arguably conceptually a different thing than what would be stored into their actual UserProfile. A secondary reason is I don’t readily understand how actual UserProfiles are stored and applied, but by storing and applying this user desire at a layer in front of all that, I don’t have to look under that rock at this time. :) A third reason is I *suspect* that this solution constrains the worst-case-scenario in how much stuff is being stored into the database as users opt in to the redesign (after all, if the redesign is successful, users will prefer to opt into it, I hope!). To the extent that all we need to know specific to a user is the fact of having selected a profile and not anything further specific to that user about that profile, well, that’s one line in a two column table rather than anything heavier that might have been entailed in storing it into the user profiles themselves. Relatedly, this profile selection table will be very easy to wipe on that fateful day when bucky becomes the default and so there’s no need to store a user’s having selected bucky. Andrew On Fri, Oct 17, 2014 at 3:30 PM, James Wennmacher <[email protected]> wrote: > Hi Andrew, > > I'm not terribly familiar with this code. The overall approach sounds good > to me. One thing I was wondering though is why you'd store the 'sticky > profile' information into a separate table. Why wouldn't you update the > UserProfile.fname for the particular user? I'm assuming (but haven't > verified) that all users have an entry in the UP_USER_PROFILE table or it > could hold an entry if a user selects something other than the default. > > James Wennmacher - Unicon > 480.558.2420 > > > On 10/17/2014 11:01 AM, Andrew Petro wrote: >> >> uPortal developers, >> >> MyUW has a need to make ad-hoc profile selection (via profile=bucky on >> /Login) less "hoc" and more sticky-across-sessions. >> >> UP-4223 took a shot at this but didn't seem to work in MyUW. >> >> https://issues.jasig.org/browse/UP-4223 >> >> https://github.com/Jasig/uPortal/pull/416 >> >> Having looked into this a bit, I'd like to propose this alternative >> implementation of making profile selection sticky: >> >> http://apetro.ghost.io/sticky-profiles/ >> >> I'm close to working code implementing this design and intend to offer >> a Pull Request once it seems to be working locally. >> >> Feedback and design input welcome. >> >> Kind regards, >> >> Andrew >> > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
