In previous versions of DSpace (5.x) and on master, it is possible to rename the "Administrator" and "Anonymous" group through either XMLUI or JSPUI.
This is a serious issue, as the refactored Group class DEPENDS on these groups having very specific names:
The most serious aspect of this is if you rename your "Administrator" group, you've essentially locked out ALL Administrative users, and the only way to change it back is via SQL queries.
This is because the AuthorizeService.isAdmin() method depends on having a group named "Administrator":
So, if a site has either previously renamed the Administrator group (in 5.x), or renames it on "master", they will end up with a DSpace that has no administrative user accounts (i.e. DSpace becomes non-functional from a Administrative point of view).
In 6.x, I think we need to do the following:
1) First, in our 5.x->6.x Flyway migrations, we need to ENSURE the 5.x Group with ID=0 is named "Anonymous", and the 5.x Group with ID=1 is named "Administrator". Then, we can assign a new UUID to each Group, in order to make them compatible with 6.x
2) Second, in the 6.x codebase we need to ensure these groups CANNOT be renamed. It MUST be blocked at the API layer, but we also may wish to add a new "isNameEditable()" (or similar) method/flag that UIs can use to determine whether to allow editing of the group name.
3) Finally, we also need to ensure these groups CANNOT be deleted. (See also DS-2687, which implies we need to also ensure they cannot be accidentally removed via a DROP...CASCADE)