User management internals refactoring

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/a28db8a652319098#

Recently we have touched PortalUser table optimization in Reviewing & Optimizing Database Queries. Here I'm about to address several improvements to that table too.

In-Portal has 2 sections, that are called "Users" and "Administrators". These sections are used to manage users and administrators. In fact both users and administrators are stored in a PortalUser table.

Only users who have set "admin" as their primary group are displayed under "Administrators" section. All other users are displayed under "Users" section. It works perfectly until regular In-Portal administrator want's to set another group (not "admin") as primary group for any of website administrators. At that moment that administrator suddenly is no longer displayed in "Administrators" section and is displayed in "Users" section.

This is bad, because user and administrator editing forms have a lot of differences. Also it's not obvious to an administrator, why he can't remove "admin" group from administrator's group list and add another group in it's place.

Proposition #1: distinguish admin or user not based on user's group, but based on new IsAdmin field in PortalUser table.

Also, when "GroupId" virtual field is displayed on user registration form, then user will have selected group as primary instead of "Member" group. This way permission change in "Member" group won't have any effect on such users. This is a logical error, since "Member" group is specified in configuration variable called "Assign registered users to group". Then user is registered, but still isn't in "Member" group.

Proposition #2: add Member/admin group (id is retrieved from appropriate configuration variables) to user groups in session (not to UserGroup table) based on newly added PortalUser.IsAdmin column after successful login.

Also what is the use of primary user group? If I recall correctly, then group's primary status doesn't affect how user permissions are calculated. Then why we need to distinguish one of the user groups with "primary" mark if it has no use is code?

If we still need it for some reason, then here is my 3rd proposition:

since user always have a primary group, then there is no need to ad it to "UserGroup" table (especially since it's added virtually after user login according to my previous proposal);
if user has non-default primary group, then it can be specified in new "PrimaryGroupId" field in "PortalUser" table via group dropdown (based on Erik's proposal in Reviewing & Optimizing Database Queries).

Related Tasks

INP-833 - Getting issue details... STATUS