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 ]
related to child of duplicate of

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
In-Portal Open Source CMS
Copyright © 2000 - 2009 MantisBT Group

Powered by Mantis Bugtracker