When a role name is changed, this breaks any page settings view roles

[CrispinF]

If a page has been set to be visible to role "test1" and the role is then renamed to "test2", the page settings remain unchanged and users in the renamed role lose access to the page.

[JimKerslake]

I'm adding event handlers: IHandleRoleDeleted: Task Handle(ISiteRole role);

IHandleRoleUpdated Task Handle(ISiteRole role, string oldRoleName);

Noting that the ISiteRole should carry with it the Guid siteId and also its new name

[JimKerslake]

cloudscribe.Core.Models 6.0.4 cloudscribe.Core.Web 6.0.37 cloudscribe.Core.Identity 6.0.8

[JimKerslake]

This is a bit harder than it seems because if an admin user edits the name of a role that they themselves are in, and if there is a restriction on the page to use that role name, then they would expect to still be able to view that page (the role name that they are in has changed, but so too has the restriction on the page). In practice the page vanishes from the navigation until after the user logs out & back in again (or an app restart) because of the caching of both user claims and the nav tree. This is confusing and I've made some efforts to try and refresh the claims and nav caching when this happens - but it still isn't perfect.

Need also to consider deletion of a role - that presumably must just remove the role restriction on all pages that referred to it? (or rather remove that reference from inside a potential csv of rolenames).

[JimKerslake]

cloudscribe.Core.SimpleContent 6.0.3

[JimKerslake]

Very belatedly I now realise that cloudscribe core has an interface called IGuardNeededRoles whose job is to prevent the editing or deletion of roles that need to be 'protected' (eg if they are referenced by Auth Policies) so it would have been possible to use that to prevent the renaming of any roles that are referenced by pages - that would have been more consistent, but also more inflexible than allowing the re-name and updating the pages to match.

[CrispinF]

Tested OK.