Summary

The August 11th making-bucky-the-default-profile-for-Madison-users-but-not-System users requirement can be fulfilled by

Adding a new profile mapper in the right spot in the existing profile mapper chain, and
Clearing the sticky profile selection table (to forget prior profile selections), and
Using particular URLs to opt out of beta to get back to Classic, and to opt out of Classic to get back to beta

on August 11th.

Problem to be solved

Currently opt-in to MyUW Beta is implemented as

a uPortal theme named "Bucky",
user ability to select that theme via a request parameter at login (and so via buttons with URLs that set this parameter)
special handling in the rendering pipeline to detect cases where the Bucky theme is being asked to do something other than render a portlet in maximized mode, such that it instead redirects to /web, which is the new angularjs-portal code.

Opting in to the beta is a matter of selecting the bucky theme. uPortal sessions under that theme have special behavior in the rendering pipeline to get the user over to the angularjs-portal front end. Once a user selects this theme, the selection sticks. Users can clear this selection by selecting a different profile instead.

On August 11th, the MyUW Beta becomes essentially an opt-out beta. Madison users are to start getting it by default. However, System users should continue to not get the beta profile.

So the solution is not quite so simple as mapping "default" to Bucky, since Bucky is not becoming the default for all users. Rather, we need to default Madison users to Bucky while leaving the logic un-changed for System users.

The problem to be solved is to switch the default for Madison users but not for System users.

Status quo

Currently, no users get Bucky by default, but users can select Bucky and that selection is then sticky so that it becomes their personal default for future sessions. This is implemented through uPortal's profile mapping sub-system, which has a chaining parent mapper step through sub-mappers in order until one maps to a profile for the new user session, falling back on a default if no sub-mapper has an opinion.

<bean id="profileMapper" class="org.jasig.portal.layout.profile.ChainingProfileMapperImpl">

    <property name="subMappers">

        <!-- The chaining profile mapper applies the first of these that maps to a non-null profile. -->
        <util:list>

            <!-- 1. If the user requested a particular profile on this login, apply it.
                 e.g. /Login?profile=mobile : selects mUniversality . -->
            <ref bean="sessionAttributeProfileMapper" />

            <!-- 2. If the user previously persisted a profile selection, apply it.
                e.g., applying a previously stored opt-in to Bucky -->
            <ref bean="stickyProfileMapper" />

            <!-- 3. If the user agent seems to be one that would benefit from mUniversality, choose that. -->
            <ref bean="userAgentProfileMapper" />

        </util:list>
    </property>

    <!-- 4. Fall back on "default" if no mapper maps. -->
    <property name="defaultProfileName" value="default" />
</bean>

Solution sketch

Part 1 : a new profile mapper

pseudocode:

class BuckyAsDefaultForMadisonUsersProfileMapper
  implements IProfileMapper {

  @Override
  public String getProfileFname(IPerson person, HttpServletRequest request) {

      String userName = person.getUsername();
      
      if (userName.contains("@")) {
        // user is a non-Madison UW System portal user
        return null; // represents this mapper has no opinion for this user
        
      } else { // username does not contain @ , user is a Madison user
     
       return "bucky"; // return the fname of the Beta theme
      }

  }

}

Part 2: Add the new profile mapper at the right spot

Pseudoconfiguration:

<bean id="profileMapper" class="org.jasig.portal.layout.profile.ChainingProfileMapperImpl">

    <property name="subMappers">

        <!-- The chaining profile mapper applies the first of these 
             that maps to a non-null profile. -->
        <util:list>

            <!-- 1. If the user requested a particular profile on this login,
                    apply it.
                 e.g. /Login?profile=mobile : selects mUniversality . -->
            <ref bean="sessionAttributeProfileMapper" />

            <!-- 2. If the user previously persisted a profile selection, 
                    apply it.
                e.g., applying a previously stored opt-out to Classic -->
            <ref bean="stickyProfileMapper" />
            
            <!-- 3. If the user is a Madison user, default to Bucky.-->
            <ref bean="buckyAsDefaultForMadisonUsersProfileMapper" />

            <!-- 4. If the user agent seems to be one 
                    that would benefit from mUniversality, choose that. -->
            <ref bean="userAgentProfileMapper" />

        </util:list>
    </property>

    <!-- 5. Fall back on "default" if no mapper maps. -->
    <property name="defaultProfileName" value="default" />
</bean>

The new mapper is the new Step 3; it opts Madison users into Bucky before the user-agent-considering mapper gets to decide mUniversality would be a good idea.

Part 3 : forget existing profile selections

With the change to make Bucky the default, existing sticky selections of Bucky are redundant and existing sticky selections of anything else should be cleared so that those users too are defaulted to Bucky and give it a try.

So the table UP_PROFILE_SELECTION should simply be emptied to clear the slate.

apetro/beta-as-default-for-madison-solution-sketch.md

Select an option

No results found