Sometimes you don't want to delete somebodies account. Disabling would be an option. This would prevent users from logging in, resetting their passwords without deleting any files and settings.
Requested here: https://help.nextcloud.com/t/ability-to-disable-users/
Change users password (Problem: User is able to reset it with email)
Alternative workaround:
That's already possible with occ user:disable <username>
, see https://github.com/nextcloud/server/blob/master/core/Command/User/Disable.php
Thanks @ChristophWurst ... Missed that :grin: Maybe it should be possibile via webinterface :grin:
cc @nextcloud/designers
@karlitschek @LukasReschke do we want this function in the interface?
Since we're thinking about it, is there a list of commands possible via occ so we can see which make sense to have in the UI and which not?
Since we're thinking about it, is there a list of commands possible via occ so we can see which make sense to have in the UI and which not?
./occ
;)
Todays master:
Nextcloud version 9.1.0 RC1
Usage:
command [options] [arguments]
Options:
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
--no-warnings Skip global warnings, show command output only
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Available commands:
check check dependencies of the server environment
help Displays help for a command
list Lists commands
status show some status information
upgrade run upgrade routines after installation of a new release. The release has to be installed before.
app
app:check-code check code to be compliant
app:disable disable an app
app:enable enable an app
app:getpath Get an absolute path to the app directory
app:list List all available apps
background
background:ajax Use ajax to run background jobs
background:cron Use cron to run background jobs
background:webcron Use webcron to run background jobs
config
config:app:delete Delete an app config value
config:app:get Get an app config value
config:app:set Set an app config value
config:import Import a list of configs
config:list List all configs
config:system:delete Delete a system config value
config:system:get Get a system config value
config:system:set Set a system config value
dav
dav:create-addressbook Create a dav addressbook
dav:create-calendar Create a dav calendar
dav:sync-birthday-calendar Synchronizes the birthday calendar
dav:sync-system-addressbook Synchronizes users to the system addressbook
db
db:convert-type Convert the ownCloud database to the newly configured one
db:generate-change-script generates the change script from the current connected db to db_structure.xml
encryption
encryption:change-key-storage-root Change key storage root
encryption:decrypt-all Disable server-side encryption and decrypt all files
encryption:disable Disable encryption
encryption:enable Enable encryption
encryption:encrypt-all Encrypt all files for all users
encryption:list-modules List all available encryption modules
encryption:set-default-module Set the encryption default module
encryption:show-key-storage-root Show current key storage root
encryption:status Lists the current status of encryption
federation
federation:sync-addressbooks Synchronizes addressbooks of all federated clouds
files
files:cleanup cleanup filecache
files:scan rescan filesystem
files:transfer-ownership All files and folders are moved to another user - shares are moved as well.
integrity
integrity:check-app Check integrity of an app using a signature.
integrity:check-core Check integrity of core code using a signature.
integrity:sign-app Signs an app using a private key.
integrity:sign-core Sign core using a private key.
l10n
l10n:createjs Create javascript translation files for a given app
log
log:manage manage logging configuration
log:owncloud manipulate ownCloud logging backend
maintenance
maintenance:data-fingerprint update the systems data-fingerprint after a backup is restored
maintenance:mimetype:update-db Update database mimetypes and update filecache
maintenance:mimetype:update-js Update mimetypelist.js
maintenance:mode set maintenance mode
maintenance:repair repair this installation
maintenance:singleuser set single user mode
maintenance:update:htaccess Updates the .htaccess file
security
security:certificates list trusted certificates
security:certificates:import import trusted certificate
security:certificates:remove remove trusted certificate
trashbin
trashbin:cleanup Remove deleted files
twofactorauth
twofactorauth:disable Disable two-factor authentication for a user
twofactorauth:enable Enable two-factor authentication for a user
user
user:add adds a user
user:delete deletes the specified user
user:disable disables the specified user
user:enable enables the specified user
user:lastseen shows when the user was logged in last time
user:report shows how many users have access
user:resetpassword Resets the password of the named user
versions
versions:cleanup Delete versions
Disable User would be useful. :+1:
Maybe just add another checkbox "disabled" next to Admin? Users should not be able to disable their own Account, to prevent Lockout
@jancborchardt Sure. Having this in the UI would be nice. Not sure if there is a nice place.
@mar1u5 maybe a Ban feature would also be useful for several functions. For example to ban a user for 5 days from the calendar function or conference function. I don't know whether it would be so good to disable the whole account. Are there any specific use-cases?
Yes there are use cases.
Banning them would not make sense I think. What would be the use-case for this? @bes1002t
Banning would make more sense if used more like an account lockout feature, user gets password wrong 5 time from the same IP = 'ban for 20 mins.'
Banning and disabling should be to separate issues I think. There are also some issue around brute-forcing login data. Maybe banning can be included there. Would also be nice.
+1 for disabling users per UI. A user should be able to disable accounts without command line access. An admin might sometimes have no shell access.
I would expect to find this in the ui, in the same place as where the admin can currently delete users, in the users area. I would expect an icon such as a circle, with a diagonal bar, to appear next to the garbage can icon for deleting them. Needless to say, we should confirm before blocking users. ;)
So probably it makes sense to replace the delete icon in the list with a 3-dot action menu like in Files. In there would be »Deactivate« and »Delete«.
Since we are thinking about occ commands in the UI, how about including files:scan (both per user for personal uploaded files and for the admin to re-scan at the system level?
@totalcaos no, sorry. This should of course work automatically, and any option like that in the interface would just be like stating something doesn't work.
@jancborchardt I see where you are coming from, but would the auto scan of work when files are uploaded (specially in bulk) via webdav or ftp when the user does not have shell access?
@totalcaos should be, yes. If it doesn't then please open a separate issue because we don't want to derail this one. :)
I added the ability to enable/disable users through the admin menu. As @jancborchardt proposed, I replaced the current delete icon with an action menu.
I also added some visual reference if a user is currently enabled or not.
I don't consider me the great design guy, so every advice for a better style is very welcome. :-)
If the general move to the "useractions menu" is considered desirable, I will prepare a PR.
Hi Thomas,
Thanks for implementing the disable user feature! Is it possible to have a
checkbox in the UI (similar to the one in the files app) so that multiple
users can be disabled/deleted through the menu? Doing this on an
individual basis can become quite cumbersome!
Use Case:
I get a lot of temporary contract workers during our busy periods (most of
them are repeat workers, so I don't have to worry about creating new
users). Currently I go in and change the password on each account
individually to prevent access once their contract period is over, and
re-issue new passwords when I get them back in.
With the multi-select checkbox I could easily select the users (who are
part of a "temp-usr" group) or the group and disable either multiple users
or users belonging to the group. (I know the second part extends the ticket
somewhat, so feel free to ignore :) )
I guess what I am saying is the ability to disable/delete multiple users
from the UI will be fantastic!
On Mon, Jul 11, 2016 at 10:22 PM, Thomas Pulzer [email protected]
wrote:
I added the ability to enable/disable users through the admin menu. As
@jancborchardt https://github.com/jancborchardt proposed, I replaced
the current delete icon with an action menu.
I also added some visual reference if a user is currently enabled or not.
[image: nc_users_enabled_hover]
https://cloud.githubusercontent.com/assets/6203906/16730266/3fdbf12e-4772-11e6-9dc7-4bdfa807be12.png
[image: nc_users_disabled_hover]
https://cloud.githubusercontent.com/assets/6203906/16730306/7b90e99a-4772-11e6-894e-a35a10dc16e2.png
I don't consider me the great design guy, so every advice for a better
style is very welcome. :-)
If the general move to the "useractions menu" is considered desirable, I
will prepare a PR.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/server/issues/283#issuecomment-231718773,
or mute the thread
https://github.com/notifications/unsubscribe/ATYLFG5IAlm-MqL5a90IUoHYXPGcid8uks5qUjVwgaJpZM4JDSnt
.
I think we could implement it like in the files section, where you have sort of a global action menu, acting on selected users.
I will look into this later that day.
Ok. Technically I could modify my implementation to be more files like.
We could have a checkbox on every username (except for the user currently logged in) and a "select all" checkbox.
We've got an action menu to operate on all selected users.
The catch is: When enabling or disabling users, everything is fine. But when mass deleting users, I'm a little bit stuck with the Undo notification. Should we provide a stack-like notification (clustering the display on really much users to delete)? Should support for undo deletion be dropped? Leaving user deletion as function to call on every user?
Need some updates. ;-)
Ouch! @Faldon that's a tough one. Personally I would get user confirmation before mass deletion and drop the "undo" function. Trying to dispaly a stacked notification could clutter up the UI quite badly.
Could it possibly be moved to the activity stream for the undo action?
I think we will need some guidance from @karlitschek, @MorrisJobke and @LukasReschke on this along with community feedback :)
For the short term, will it be practical to leave out the "delete" functionality and focus on purely the "disable" action
@totalcaos mass selection is an entirely different thing, so please again: open a separate issue for that and let's focus on one thing at a time. :)
@Faldon great stuff! :) Check out the classes / HTML structure of the dropdown in the Files app is probably easiest to get the styles over. You could also just open a work-in progress pull request and we can collaborate on this.
Also, rather than a visual indicator I would say we should have a separate navigation section on the left called »Disabled« where disabled users are moved into. They should not be shown in the regular list and groups anymore.
@jancborchardt Than I will think I will revert to my first version, with a dropdown menu on every user, for now. Instead of the red stripes we go with a "Disabled" user group.
@totalcaos I save the code for the mass editing in a separate branch. Than we can discuss, how to implement it best and with save defaults.
@Faldon @jancborchardt that's cool. I'll raise another ticket to deal with bulk disable/delete of users and link it back to this ticket for reference.
New PR (rebase on master) is in #1234
Implemented in #1234
Is there a way to disable the user from the OCS Api?
Is there a way to disable the user from the OCS Api?
The OCS API provides you the _enabled_ status (https://docs.nextcloud.com/server/12/developer_manual/client_apis/OCS/index.html#user-metadata) with the parameters true
or false
😉
To disable/enable a user you can use the WebUI or the occ
command documented over here:
https://docs.nextcloud.com/server/12/admin_manual/configuration_server/occ_command.html?highlight=disable%20user#user-commands
Most helpful comment
I added the ability to enable/disable users through the admin menu. As @jancborchardt proposed, I replaced the current delete icon with an action menu.
I also added some visual reference if a user is currently enabled or not.
I don't consider me the great design guy, so every advice for a better style is very welcome. :-)
If the general move to the "useractions menu" is considered desirable, I will prepare a PR.