we noticed some similar strange behavior recently, as we tried to implement multiple themes. essentially, we are adding a new theme, and we wanted to transition people to it by group; however, in our test environment, it appears that everyone is getting the default theme... no matter what their individual profile has been configured to display. we will be exploring this further; however, clearly the user override for theme is not being applied correctly.
On 1/22/09 2:37 PM, "Jen Bourey" <[email protected]> wrote: Hi all, While looking into import/export options for multiple user profiles, I seem to have stumbled across some issues with uPortal's RDBM user and layout classes. I can manually add new profiles and user agent mappings to the database for existing users without issue. I start having problems when I try to log in with users that aren't yet created in the uPortal database (for example, an LDAP user who's never logged into the portal before) and expect to be able to edit the layout while logged in with the second profile. I had assumed I'd set up something in the database incorrectly, but after looking at the code, I'm not quite sure the code is properly set up to handle this scenario. When a user first logs into the portal, the code copies the appropriate number of profiles from the default user. From looking at the code, I believe the following logic occurs the first time a user makes a layout change: 1. Check UP_LAYOUT for a layout id which matches the current user and profile id. 2. If none is found, set the expected layout id to "1". 3. Try to get the layout from the table. If none is found, add one with the expected id. Problems: 1. If the user has multiple profiles, the layout will be assumed to be "1", even if layout "1" has already been created for another profile for that user. In this case, another one wouldn't be inserted, but the profile would be configured to use this already-existing layout. 2. The layout id in UP_USER_PROFILE is set when the layout is created, but the structure and theme ids are never updated from null. I have no idea why, or what the consequences of having a null structure and theme id is. It seems to only cause problems when a user has multiple profiles. I can add code to look up the structure and theme ids for the profile for the default user. 3. Profile IDs seem to currently have a particular meaning and be expected to be the same across all users and profiles. For example, if for the default user, profile 2 is intended to be the mobile profile, profile 2 is expected to be the mobile profile for all users. This situation isn't particularly compatible with import/export, and I'm not sure what the best way to handle it is. It seems like we could use the name of the profile to find profiles rather than the id, or perhaps create a new column in UP_USER_PROFILE that would be an identifier for each profile that would be unique per user and consistent across users. Layout IDs are also mapped in a similar problematic fashion. 4. Profiles are only created when the user is first created. This means that if a profile is added to the template user after a user has already been created, he or she will never get the new profile. - Jen -- 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
