Q1. What is the problem that you are trying to solve?
It should be possible to deactivate users. In a company environment users are not deleted but disabled first.
Q2 - Who is impacted?
Everyone, but especially someone in a company environment.
Q3 - Why is it important and/or urgent?
Legal reasons. User must not be able to log-in, but it must be known, to what passwords a user once had access to.
Q4 - What is your proposed solution? (optional)
Right-click user → disable user.
Q5. Community support
People can vote for this idea to show traction:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
@passboltUser this is actually already the case. When an admin delete a user the record is not deleted but a flag is set to 1 in the users table deleted field. The UI should be improved however to allow to see the soft-deleted users.
A suggestion on what may happen when clicking ~“disable user”: The user may either be grayed but be still present with the other users, or may be moved to an own “Disabled Users” table at the top menu. But it should be possible to re-enable the user, so he may not disappear from the UX.
Also, the admin, when disabling a user, may be able to set the user to ~“only visible to admins”.
Also, it would be nice to see which passwords a user has shared (not his private ones).
I wouldn’t test that in production as this is not a supported feature, but they are good chances it will work unless you have recreated a user with the same username again.
Our plan was to implement the type of feature your describe, but we didn’t finish it yet.
Ok, good to know you were planing to implement this feature.
I went straight to the users table (/sql.php?server=1&db=passbolt&table=users&pos=0) and set the “active” and the “deleted” fields for the user to 1. The user is not in the users overview anymore, guess this workaround is ok for now (I can set the user back to 0 if needed). Thanks.
Sorry, I changed the active and deleted values in my other post to the correct ones I meant.
Thanks, was not sure about the “active” row. I think one shouldn’t touch the default value there for an active user, this way one knows that the user once was using Passbolt and has explicitly been disabled by a admin now (“deleted” to 1).
i think this is still open. When I delete a user I get an notification that the user will be deleted permanently. This is not what I was expecting, reading remy’s post here.
Maybe you can even add in an option to reactivate the user, should it be necessary?
Hi,
when is this feature planned to be integrated?
Also an implementation for the Active directory sync that takes into account the “userAccountControl” values [1] would be desirable ( e.g. 512+2 = 514 → disabled account ).
We recently switched to Pro version for MFA-support and this feature would have been useful for us.
Some users seem to “forget/postpone” to set it mfa up … if we could disable them they would activate it straightaway.
Thank you for your feedback. It is not possible currently to force all users to setup MFA nor disable them. It is something we have on our radar but there is no ETA yet for these features.
As an admin, you can anyway list users who have MFA disabled and send them a gentle reminder.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)