Hi all, I'd like to discuss the current uPortal support for multiple profiles and layouts and solicit some feedback on a proposal for making our support a little more modern and robust. Multi-profile support issues were first documented in JIRA at and are currently being explored by Unicon's cooperative development program.
*Background* First of all, for those of you who might not be familiar with uPortal's layout architecture, I'll go into a brief summary of the way layouts and profiles current work in uPortal. When a user logs into uPortal, the following relevant steps happen to produce HTML content: 1. uPortal retreives a user profile for the current user (person) and user agent (browser + computer, roughly). The profile has an ID (unique per-user), a name, and a description and points to a theme, structure, and layout id. 2. uPortal retrieves the layout indicated by the profile and represents it as XML. 3. Once the layout's XML structure is constructed, the portal applies the specified structure XSLT to transform the original generalized nested folder XML into a more layout-specific form (in the default case, tabs and columns). 4. Next uPortal uses the desired theme XSLT to transform this intermediate XML document into XHTML. In theory, uPortal supports multiple profiles per user. If more than one profile exists for a particular user, the profiles might either share one layout, or, in theory, point to separate layouts. *Current Issues* In practice, we currently have a couple issues with our profile/layout architecture: 1. Profile IDs are meaningful. The browser mapping file assigns user agent regexes to a particular profile numerical ID, which means that for all users, profile 1 must be the desktop profile, while profile 2 must be the alternate profile. This strategy is not particularly compatible with import/export and it prevents us from ever turning those IDs into real primary keys. 2. Profiles are only created for a user when the user is first created. If you add a second profile for the template user, new users will be created with both profiles, but older users will never have access to the newly created profile. If a user doesn't have a particular profile, s/he will get the system profile instead. This sort of appears to work at first, but the user is actually getting the system layout instead of his or her actual layout even if the desired layout already exists. 3. uPortal import/export doesn't currently support multiple layouts for one user. *Proposal* To handle the first two problems listed above, I'd like to propose that we match profiles and layouts by String keys rather than by the ID field. We could either use the existing name or potentially create a new shortname key for each row. When a user logs in, the system would then attempt to look up the desired profile by name, and then, if it didn't exist, look up the matching profile under the template user. If such a matching profile existed in the template user, we could create a new profile for the current user based on that template profile. The biggest concern I currently have with this proposal is that we make sure that existing data can easily be updated to the next version of uPortal. Since our current data essentially contains one defaultTemplate profile, but doesn't use a consistent name for the profile, we might need to do something to ensure that the imported profiles are created with a matching name. Are there many existing installations that really have multiple theme/stucture combinations for different user agents? Does anyone have thoughts on this proposal? - Jen -- Jen Bourey -- 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
