In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Relationship Graph

[ View Issue ] [ Dependency Graph ]

Viewing Issue Simple Details
ID	Category	Type	Reproducibility	Date Submitted	Last Update
0001031	[In-Portal CMS] Data Management	refactoring	always	2011-04-03 11:16	2012-11-27 09:22

Reporter	alex	View Status	public
Assigned To	alex
Priority	normal	Resolution	fixed
Status	closed

Summary	0001031: User management internals refactoring
Description	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 wants 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 UserType field in PortalUser table (0 - user, 1 - admin, 2 - new ...). 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.UserType column after successful login. Proposition #3: Transform UserGroup.PrimaryGroup field into PortalUser.PrimaryGroupId. This way user's primary group will be stored in PortalUser.PrimaryGroupId (will be NULL by default). Display "primary icon" on "Groups" tab during user/admin editing by comparing group id being printed to group id from user record. Also "Set Primary" functionality will be changed.
Additional Information

Web Development by Intechnic

In-Portal Open Source CMS