Deprecate SiteOwner permission and retain Administrator as system role

[MikeAlhayek]

Fix #11920
Fix #16763

Site Owner Permission Deprecated, Administrator Role Retained as System Role

The SiteOwner permission has been deprecated and will be removed in future releases. To avoid breaking changes, a fast-track migration has been added that automatically assigns the Administrator role to any user with the SiteOwner permission.

The Recipes feature now authorizes against the new ManageRecipes permission, instead of relying on the deprecated SiteOwner.

If the existing Administrator did not have the SiteOwner permission, a new role will be generated and assigned as the system admin role. This role may be named Admin, SiteAdmin, SiteAdministration, SiteOwner, or Admin{N}, where {N} depending on availability to ensures a unique role name. Additionally, any user previously assigned the SiteOwner permission will automatically be granted this newly created role.

Recipes Feature

New 'Manage Recipes' Permission Added

Previously, only users with the SiteOwner permission could run recipes. Now, a new ManageRecipes permission allows you to grant recipe management capabilities to any role, providing greater flexibility in permission assignment.

Themes Feature

Users with 'Apply Theme' Permission Can List Themes

Previously, only users with the SiteOwner permission could list themes. Now, users with the existing ApplyTheme permission can also list and apply themes, enhancing theme management capabilities.

[Piedone]

See #16763 (comment).

[gvkries]

I don't think we should add a special flag like HasFullAccess to roles. Instead we may want to have a special system role for site owners though, to replace the SiteOwner permission with that. Adding something like HasFullAccess is quite similar to just continue using a special SiteOwner permission as we currently do. When we add a special system SiteOwnerRole, we would just use that for granting all access and it would be a clear separation of concerns. But I'm not sure if it's worth the effort.

Concerning the Type property, I don't see we would ever have anything else than System and Standard, so I would go for a simple flag (IsSystemRole or something like that). No need for another enum. And it doesn't have to be persisted as well.

[MikeAlhayek]

@gvkries the HasFullAccess property was replaced with Owner type. Let me know if you have anything else.

[sebastienros]

the HasFullAccess property was replaced with Owner type. Let me know if you have anything else.

I am still seeing it in recipes. Maybe reflect it there too, or at least rename with IsOwner if there is absolutely no reason to use any other type in recipe or there is no way there will be a new type in the future. Otherwise use a RoleType string instead.

[MikeAlhayek]

I am still seeing it in recipes. Maybe reflect it there too, or at least rename with IsOwner if there is absolutely no reason to use any other type in recipe or there is no way there will be a new type in the future. Otherwise use a RoleType string instead.

@sebastienros yes this way missed. Should be fixed now.

[gvkries]

LGTM, I've only some minor notes/improvements if you don't mind.

Thanks @MikeAlhayek

[MikeAlhayek]

@sebastienros do you like to add anything else here or you good with it?

[sebastienros]

We need to make it work for new sites.

[MikeAlhayek]

It already does as during create roles will have no records so this logic will not be called. But for safety, I added a check against claims.

[sebastienros]

Read settings["AdminRoleName] so users can define what they want to use.

[MikeAlhayek]

This can now be configured from the settings using OrchardCore_Roles:AdminRoleName