User management internals refactoring

[Alexander Obuhovich]

Recently we have touched PortalUser table optimization in this discussion. 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 this discussion).

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

Hi Alex,

I'd recall here that it's very usefull to have more than 1 admin group, for example 1 admin group tp manage everything, and another admin group with only some privileges.

Will your new parameter "isAdmin" will remove this ability?

p

2011/4/2 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

According to my previous post that IsAdmin field will be used to display admin users in "Administrators" grid only. It's not related to permission management at all.

[Dmitry A.]

Hi Alex,

I have carefully reviewed your proposals and like and support some of them - more details below:

1. Yes, I would add a new field to the Users table to differentiate user type, but would call it UserType instead of IsAdmin. This will give us more flexibility in the future when we need to add new sections like Customers, Employees and so on. In result we'll have something like UserType: 0 - user, 1 - admin, 2 - new... What do you think?

2. No, I would keep such thing as a User Primary Group for a least three reasons:

a. it's used in In-Commerce as default User Pricing setting

b. it's used in In-Bulletin to show which User Group user belongs to (can belong to multiple)

c. there is a chance that we might want to use it in other places so we need  to have that possibility.

3. Yes, I would add a new PrimaryGroupId field to the PortalUser table and remove it from UserGroup table + make according changes to Users SQLs (will improve performance).

Thanks and let me know what do you think on above.

Cheers!

DA

[Alexander Obuhovich]

Ok for all.

Since 2 and 3 item of your post is about my 2nd proposal, then what do you think about my 3rd proposal?

[Dmitry A.]

After further reviewing I have the following comments:

1. Let's keep the same Interface for showing User Groups and setting the Primary User Group on separate tab and NOT a drop-down as suggested by Erik. We still going to have PrimaryGroupId in Portaluser table.

2. Yes, I agree on your idea with adding to GroupList in SessionData based on new created UserType field in PortaUser.

Please create the task!

DA

[Alexander Obuhovich]

Here is the task: http://tracker.in-portal.org/view.php?id=1031