Cleanup Identity

[fretje]

I started working on #385

• re-design permissions
• consistency
• rename IIdentityService to IProfileService
• rename StatsController to DashboardController
• remove roleclaimscontroller
• add personalController and move myauditlogs and mypermissions there
• move FSHRoles to shared project
• remove isdefault from roledto

An accompanying PR is following on the blazor repo...

Will update this PR with more cleanup, but please review already!

[fretje]

Think I'm almost there...

Still not sure about the whole "Profile" name thing... still feels like it should all go into one "userservice"... but that might get a bit bloated... maybe using partial classes in different files?

I've created some events ApplicationRoleUpdated and ApplicationUserUpdated, which I use now in the ClearUserPermissionCacheHandler to clear the userpermission cache (the one that's used in UserService.HasPermission which is called on every request).

I have now only added the publishing of these events in the places where it's relevant for that specific handler... we should probably add all the event types and send them everywhere where it's necessary...
I do think we need some more refactoring then, as there are many different places where a user is updated or created now for instance...

[xlogex]

Probably the street of the partial classes could be a less bloated road.
The fact remains that the list of permits is always long, and if you split them in 2 or more the list how many they end in other files? .... evalueate afterwards.

[iammukeshm]

Could you please update the postman collections too? since there are a couple of controller changes that I can see,

Also, do we need to re-generate migrations ?

[fretje]

Concerning migration: only some fields been removed, so in theory it's not needed (but the database will contain some unused fields)... But I suppose they will have to be re-generated anyways for a release... That should actually be part of the build process I think...

I have never done postman updates before... is that simply exporting again? I'll have a look later...

[xlogex]

Concerning migration: only some fields been removed, so in theory it's not needed (but the database will contain some unused fields)... But I suppose they will have to be re-generated anyways for a release... That should actually be part of the build process I think...

I have never done postman updates before... is that simply exporting again? I'll have a look later...

about postman we can regenerate after ... (maybe exist import nswag.json file present in swagger)

[xlogex]

[fretje]

Ok, the postman collection has been updated...

[fretje]

Still not sure about the controllernames "Personal" and "Profile" and "users"... seems like they overlap somewhere...

But I hear no other suggestions? ;-)

[xlogex]

I think they are well organized.
Personal: aggregate personal information (log, credentials/grant)
Profile: aggregate single user actions (register, update info, recovery ...)
Users: Manage users

[CanMehmetK]

_context is very general
as suggested using variables with full
like _applicationDbContext or some like

[CanMehmetK]

this is more sensible.

[iammukeshm]

This looks neat. But wouldn't it be better to merge user and profile controller into a single user controller

Create a new user sounds better than create a new profile.

[fretje]

Jep... thinking GET /api/profile goes to personal (GET /api/personal/profile) and the rest go to users...

I'll have a looksie later ;-)

[fretje]

Hmm... the PUT /profile doesn't really fit under users, as that's also only for the currently logged on user...
I suppose that one also goes to personal.
There isn't a way now to actually update (or delete) users from the user admin side... I guess if we were to add that, that would be other endpoints under /users then...

[fretje]

Something like this?

[fretje]

I've used partial class to separate UserService into several files now...
Still feels a bit cluncky...

I'm wondering if we can't just create RequestHandlers like we do in the applicationProject but then in the infrastructure project... that would be the best solution I think... Now that I've already added AddMediatR(Assembly.GetExecutingAssembly()) in the infrastructure project (for the InvalidateUserPermissionCacheHandler), I think it would "just work".

[frankyjquintero]

It seems to me a breakthrough in terms of the development and separation it is taking. As for the events from infrastructure I consider viable but must be in another PR, the mixture of several ideas confuses the update of projects in progress