feat: allow to remove default `admin` user

[astappiev]

The general idea of this PR is to allow the removal default admin user.

Also in this PR:

• Replace check doesAdminUserExist with doesAnyAdminUserExist, if false, keep the current behaviour of creating an admin user with default password
• Refactor UserCreateRequest, UserUpdateRequest and BookLoreUser to reuse the common UserPermissions class
• Remove security check from deleteUser method of UserService, it was broken, and it's already applied via @PreAuthorize check
• Rename selectedLibraries to assignedLibraries to keep it consistent in UserCreateRequest
• Add ability to change Can Manipulate Library and Admin permissions in User Management

Maybe we should allow to change the password for current admin himself, otherwise this is impossible to perform after the first change on the first login. Or an option for a user to change their own password would be nice to have in general.

[acx10]

@astappiev Your changes look really solid overall, thanks for putting this together!

The only concern I have is around allowing admins to kick each other out. Personally, I’m not in favor of that. I think a cleaner approach would be to introduce the concept of a super admin with elevated privileges, while keeping other admins slightly restricted in terms of managing peers.

Regarding the ability for admins to change their own passwords, completely agree. That’s been on my backlog as well. It’s definitely something we should support, either via an admin panel or a basic “change your password” feature.

Would you like to take a stab at the super admin + password update features, or should I pick that up? I’ve been busy lately… working on a bunch of (arguably) less important features, as you may have noticed in the commits. :)

Really appreciate all the good work you’re doing here!

[astappiev]

The only concern I have is around allowing admins to kick each other out. Personally, I’m not in favor of that. I think a cleaner approach would be to introduce the concept of a super admin with elevated privileges, while keeping other admins slightly restricted in terms of managing peers.

I can't agree, IMHO, the app is designed for family/friends auditory, I don't expect any issues there. Even if that happens, the last word is always given to the one who hosts it. If someone's ex 👿 removes their admin permissions, one can always restore them via simple SQL query 🫡

Regarding the ability for admins to change their own passwords, completelly agree. That’s been on my backlog as well. It’s definitely something we should support, either via an admin panel or a basic “change your password” feature.

This can easily be done by removing one if condition in UI, but would be better to have “change your password” feature.

Would you like to take a stab at the super admin + password update features, or should I pick that up? I’ve been busy lately… working on a bunch of (arguably) less important features, as you may have noticed in the commits. :)

I don't need it myself as my passwords are going to be managed via central ID, but I can try to implement “change your password” feature. Also, will make the password nullable, because now if you login with Forward Auth, your password is set to a random 32 char string. It's secure enough, but not fancy.

Actually, I'm not familiar with Spring or Angular, I have some projects with Quarkus and React thought.

[acx10]

The only concern I have is around allowing admins to kick each other out. Personally, I’m not in favor of that. I think a cleaner approach would be to introduce the concept of a super admin with elevated privileges, while keeping other admins slightly restricted in terms of managing peers.

I can't agree, IMHO, the app is designed for family/friends auditory, I don't expect any issues there. Even if that happens, the last word is always given to the one who hosts it. If someone's ex 👿 removes their admin permissions, one can always restore them via simple SQL query 🫡

Regarding the ability for admins to change their own passwords, completelly agree. That’s been on my backlog as well. It’s definitely something we should support, either via an admin panel or a basic “change your password” feature.

This can easily be done by removing one if condition in UI, but would be better to have “change your password” feature.

Would you like to take a stab at the super admin + password update features, or should I pick that up? I’ve been busy lately… working on a bunch of (arguably) less important features, as you may have noticed in the commits. :)

I don't need it myself as my passwords are going to be managed via central ID, but I can try to implement “change your password” feature. Also, will make the password nullable, because now if you login with Forward Auth, your password is set to a random 32 char string. It's secure enough, but not fancy.

Actually, I'm not familiar with Spring or Angular, I have some projects with Quarkus and React thought.

I’m still unsure about having multiple admins, so I’ll revisit this in a couple of weeks to evaluate the best approach.

Thanks a lot for implementing the self-service user profile edit and password reset features, they’ll be a great addition! Though I did make a few tweaks to them.

BTW, I was considering using Quarkus for Booklore when I first started, but I found Panache a bit strange to work with.

[astappiev]

I guess this is already re-impelemnted. Not sure if the refactoring I made is still relevant. Should I rebase?