Open irinaz opened 4 months ago
I need to have a think about this one. If we delete the user roles then if the logged in user is not user 1 then the logged in user will no longer have permissions to either run update.php nor use this module.
Tried another approach, duplicate the admin role, assign to the current user, then delete. Should work.
That sounds great and more consistent with what I have been doing manually. Currently I see two roles called "Administrator" - one is migrated to D7. I manually rename that role to "Administrator D7" and add role "Administrator" to all admins from D7 db. I usually do not delete that role in case something is offset with permissions
Roles were not assigned correctly in the latest commit. Original Administrator role did not have label and because of that is not editable
.
Also small type in new role name (Old dministrator) missing "a"
@docwilmot , thank you for working on this!!
Original Administrator role did not have label and because of that is not editable
I dont think that is the fault of this module though, I think you need to ensure your roles have labels prior to upgrade. If you did a normal D7 to Backdrop upgrade doesnt the same thing happen? The D7 database I use for testing the D7 admin role has a label so it migrates just fine.
@docwilmot , I will test another site and report results. I was using standard D7 instance, with Role "administrator" and url admin/people/permissions/roles/edit/3 .
I would like to suggest name "D7 administrator" instead of Old administrator to make it clear where it comes from.
Just to be clear, the "old administrator" is the pre-migrate admin role from the Backdrop site, which should be deleted. Maybe we should name it "Migration administrator"
Oh, I see now. Let's try this name for this role and see what will be feedback from community.
When we are upgrading D7 to BDCMS through D2B we have existing json file for roles. When we are running user module upgrade additional role "Administrator" is being created and can cause significant confusion because permissions might be very different.
Proposed solution was to remove json config files related to users after D7 db is imported but before running step /core/update.php