If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Problem with group membership after migration from 2.18 to 3.0.1

RESOLVED WORKSFORME

Status

()

Bugzilla
Installation & Upgrading
RESOLVED WORKSFORME
10 years ago
8 years ago

People

(Reporter: Tomasz Jaszowski, Unassigned)

Tracking

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Build Identifier: 3.0.1

We have migrated 2.18 to 3.0.1, and after it some of users 'lost' privileges to some groups



Reproducible: Always

Steps to Reproduce:
1. at 2.18 set 'Can turn these bits on for other users' but do not set 'User is a member of these groups' for group X
2. at 2.18 it looks like you are a member of group X
3. migrate to 3.0.1
4. at 3.0.1 it looks like you are not a member of group X
Actual Results:  
difference in privileges after conversion

Expected Results:  
no difference in privileges after conversion

during DB conversion, script should check if user has 'Can turn these bits on for other users' set for group and add 'User is a member of these groups' if it's missing

or

bugzilla should assume if user 'Can turn these bits on for other users' he's also member of these groups
(Reporter)

Comment 1

10 years ago
or 

bugzilla should assume if user 'Can turn these bits on for other users' he's
same privileges as member of these groups

Updated

10 years ago
Assignee: user-accounts → installation
Component: User Accounts → Installation & Upgrading
Keywords: qawanted
OS: Linux → All
Hardware: PC → All
Version: unspecified → 3.0.1
(Reporter)

Comment 2

10 years ago
btw.

select * from user_group_map;

+---------+----------+---------+------------+
| user_id | group_id | isbless | grant_type |
+---------+----------+---------+------------+
|      10 |       49 |       0 |          0 |
|      10 |       49 |       1 |          0 |
|      14 |       40 |       0 |          0 |
|      14 |       40 |       1 |          0 |

If we assume that user that 'Can turn these bits on for other users' is also a member of this group we will need only one record for it.


select * from user_group_map - for user with privileges problems:
+---------+----------+---------+------------+
| user_id | group_id | isbless | grant_type |
+---------+----------+---------+------------+
|      30 |       32 |       0 |          0 |
|      30 |       33 |       1 |          0 |
|      30 |       34 |       0 |          0 |
|      30 |       34 |       1 |          0 |
|      30 |       35 |       1 |          0 |

problem is with accessing group_id = {33,35}, and no problems with accessing group 34

Comment 3

10 years ago
Hey Tomasz. It looks like there's no problem in the database there for user_id 30.

Did you keep your data/ directory from 2.18 during the upgrade, per the upgrade instructions in the Release Notes? Or have you changed any of your parameters, particularly in the Group Security section of editparams.cgi?
(Reporter)

Comment 4

10 years ago
(In reply to comment #3)
> Hey Tomasz. It looks like there's no problem in the database there for user_id
> 30.

DB looks ok, but I would use one line for storing informations that are now in 2lines... I would do it by assuming that if record exists and isbless = 0 user is in group, isbless = 1 - user is in group and can turn these bits on for other users;

in that way my 'problem' with privileges would be solved and user_group_map table would look cleaner (IMHO)


> Did you keep your data/ directory from 2.18 during the upgrade, per the upgrade
> instructions in the Release Notes?

yes,

>  Or have you changed any of your parameters,
> particularly in the Group Security section of editparams.cgi?
> 

no

>

(Reporter)

Comment 5

10 years ago
I solved this 'problem' with privileges by manually adding users with 'can turn these bits ...' also to group member.

so now it's working ok (as in 2.18)

Comment 6

8 years ago
We intentionnaly removed this implicit relationship in Bugzilla 2.22, see bug 318171. This means that being able to add/remove people from a group no longer means you are a member of this group. So the upgrade did what we expected it to do.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
(Reporter)

Comment 7

8 years ago
(In reply to comment #6)
> We intentionnaly removed this implicit relationship in Bugzilla 2.22, see bug
> 318171. This means that being able to add/remove people from a group no longer
> means you are a member of this group. So the upgrade did what we expected it to
> do.

Thank You for explanation
You need to log in before you can comment on or make changes to this bug.