I reviewed the current implementation, and while working partly, I found an easier way to implement and complete this one, which happens to also solve
JS2-915 at the same time.
I'm using the current user its fully resolved (hierarchically even) principal list, which is available from the Jetspeed wrapped UserSubjectPrincipal.
Having those, and when determined the current user does not have 'the' admin role (determined from the PortalConfiguration),
the current user will only allowed to modify (both add and delete) principal associations for a principal when itself has access (be assigned to) these principals.
And, going even a bit further: I also disable editing any user principal property/configuration when that user principal happens to be assigned this admin role (except for admin role users itself).
That is: I only evaluate if the user principal as this admin role directly assigned. So, not checking against possible hierarchical derived admin role because that is very expensive and complex which we currently only do for a logged in user itself.
Finally, while I was at it anyway, I've also cleaned up the "tabs" a bit by renaming/replacing the "User Profile" tab for Roles and Groups to a new "Status" tab,
and likewise splitted off the same functionality a new "Status" tab for Users so the Users "User Profile" tab now really only provides "profile" management.
AFAIK, all works now as can be expected (as described above), and thereby includes the requested functionality from
JS2-915 too, automatically