0003483: some admin users permissions not completly upgraded from 0.17.5 to 0.18.0 - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0003483	mantisbt	upgrade	public	2004-01-05 18:45	2004-08-29 02:02

Reporter	pascalvmf	Assigned To	vboctor
Priority	normal	Severity	major	Reproducibility	have not tried
Status	closed	Resolution	fixed
Platform	Intel	OS	Mandrake Linux	OS Version	9.2
Product Version	0.18.0
Fixed in Version	0.19.0rc1

Summary	0003483: some admin users permissions not completly upgraded from 0.17.5 to 0.18.0
Description	I had 2 admin users on 0.17.5 after upgrading to 0.18.0, I had this strange behaviour : my user is displayed as (administrator) in upper left when clicking admin I am directly on admin group page If I modify the url from admin_groups to admin_users if works, from there I can add a user (with admin privilege), but I cannot modify any users options (access denied)
Steps To Reproduce	migration from 0.17.5 to 0.18.0
Additional Information	To circumvent this I used my newly created admin user to : set a manager only access to my old admin users set administrator access again to my old admin users then all worked properly for them ... I don't know if it is reproducable - something might be missing from the sql upgrade scripts.
Tags	No tags attached.
Attached Files	admin_admin_del.diff (1,264 bytes) Index: admin/upgrades/0_18_inc.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/admin/upgrades/0_18_inc.php,v retrieving revision 1.18 diff -u -r1.18 0_18_inc.php --- admin/upgrades/0_18_inc.php 3 Aug 2004 23:45:15 -0000 1.18 +++ admin/upgrades/0_18_inc.php 4 Aug 2004 15:47:07 -0000 @@ -548,5 +548,30 @@ 'Rename Column', "ALTER TABLE mantis_custom_field_table DROP require_close" ); + $upgrades[] = new FunctionUpgrade( + 'delete-admin-over', + 'delete any project level access overrides for admin users', + 'upgrade_0_18_del_admin_override' ); + + function upgrade_0_18_del_admin_override() { + global $t_user_table, $t_project_user_list_table; + + $query = "select p.user_id + FROM $t_project_user_list_table as p, $t_user_table as u + WHERE ( ( p.user_id = u.id ) AND ( u.access_level >= 90 ) )"; + $result = db_query( $query ); + $t_count = db_num_rows( $result ); + for ( $i = 0 ; $i < $t_count ; $i++ ) { + $t_row = db_fetch_array( $result ); + $t_user = $t_row['user_id']; + $query = "DELETE FROM $t_project_user_list_table + WHERE user_id=$t_user"; + db_query( $query ); + } + + return true; + } + + return $upgrades; ?> \ No newline at end of file admin_admin_del.diff (1,264 bytes)

vboctor 2004-01-05 23:09 manager ~0004854	This problem is caused by the bug which is fixed in 0003389. I will keep this one open in order to add to the upgrade script code that would delete project-specific access levels for users with access level greater than or equal to ADMINISTRATOR.

vboctor 2004-02-20 20:38 manager ~0005072	For users with MySQL 4.0.0 or higher (I think that's the minimum requirement to be able to run the following query), BACKUP your data and run the following query: DELETE FROM mantis_project_user_list_table USING mantis_project_user_list_table, mantis_user_table WHERE ( ( mantis_project_user_list_table.user_id = mantis_user_table.id ) AND ( mantis_user_table.access_level >= 90 ) )

grangeway 2004-08-03 11:08 reporter ~0006601	Reminder sent to VictorBoctor hmm, does this need to be covered by 0.19 upgrade routiens?

thraxisp 2004-08-03 11:35 reporter ~0006602	Paul, you may also want to look at the related problem. There are two cases here. I can see where you might want to elevate a user to administrator level for a single project based on the capabilities that could be set (e.g., admins add project documentation). I can also see where you would want to downgrade an admin for a project to avoid emails, etc. associated with the project.

vboctor 2004-08-03 17:52 manager ~0006611	Paul, we should add an upgrade step, however, the one below requires MySql 4.0 which is higher than our minimum MySql requirements. So the upgrade step would have to be implemented in a different way. I wouldn't delay 0.19.0 because of this, but if we get it in that would be good. thraxisp, an ADMINISTRATOR must be an ADMINISTRATOR for the whole system (i.e. all projects). If the user wants to do what you are explaining, then he should added a SUPERUSER access level and use it accordingly.

thraxisp 2004-08-04 10:47 reporter ~0006632	A patch for the admin upgrade system is attached. This removes user entries from the project_user_table where the user is already an admin globally. It replaces the code patches in 0004202.

jlatour 2004-08-06 18:07 reporter ~0006734	OK, I think you can commit that. Perhaps we need to replace 90 with the ADMINISTRATOR constant?

thraxisp 2004-08-06 20:38 reporter ~0006738	Fixed in CVS