...
There would be backwards-incompatible consequences to this refactor. The /v3/participants APIs could no longer be used to create and manage administrative accounts. I don’t know who uses these for that purpose, at least the Bridge Study Manage would need to revise the UI it has to list all admins/users in one giant list (currently under the legacy panel). That API is still useful, but it would only return true participant accounts.
Notes on refactoring…
General
Explicitly mark administrative accounts before we migrate roles, because right now that's the way we determine these kind of accounts.
AccountDao & AccountSecretDao
Basically fine as is. AccountDao.getAppIdForUser is weird. AccountDao.getPagedExternalIds is weird but probably legacy.
ParticipantVersionService
Should monitor changes to the Accounts table that are done through ParticipantService, not AccountService
ConsentService, EnrollmentService
AccountService -> AccountDao
AccountService & ParticipantService
Could use an abstract parent. e.g. do you call "getAccountId" on account service or participant service? Maybe both is OK. Deleting an account: lots of common code between deleteAccount() and deleteParticipant.
AccountService
move authenticate, changePassword, reauthenticate, deleteReauthToken, verifyChannel to the AuthenticationService.
ActivityEventService: should be used in ParticipantService
StudyActivityEventService: should be used in ParticipantService
ParticipantVersionService: should be used in ParticipantVersionService
It does seem like simple methods to get the ID of an account or the like could continue to use AccountService.
ParticipantService
AccountService -> AccountDao
Any code related to roles and/or organizations can be removed to AccountService;
any attempt to manipulate an admin account through this service should fail fast;
updateIdentifiers: authenticate in the controller as part of the security check so you can take these auth methods out of AccountService and ParticipantService
Auth: AuthenticationService, AccountWorkflowService, OAuthProviderService
These are all related and could be combined, except that it would make an unwieldy service. Maybe we could have a front controller that delegates to a set of implementation classes so external classes only deal with an AuthenticationService, but we're not maintaining a monolith.
AuthenticationService should drop reference to AccountService and ParticipantService and work only with AccountDao and AccountSecretDao
AccountWorkflowService should drop reference to AccountService and use AccountDao.
UserAdminService
Fine as is (a crazy service to make integration testing palatable)
AccountController
add paginated API to retrieve admin accounts in the app (across all organizations or no organiations);
access to these methods would require app:admin or system:superadmin powers;
all methods should only operate on admin accounts;
UserManagementController
it may be simpler and easier to create enrollment records directly in the account for testing purposes. This would remove the consent service and the enrollment service;
the account service user delete should delete from all those other services, so we don't have to reference userAdminService to properly delete an account.
Expanded permissions model
...