Enhancement: Admin Interface #1791

Open
opened 2026-03-22 13:37:59 -05:00 by GiteaMirror · 9 comments
Owner

Originally created by @mtettke123 on GitHub (Jul 29, 2022).

As most self-hosted installation will probably have registrations disabled, a admin interface to add/delete users would be VERY cool. Something like vaultwarden has (invite user, see user list, see space consupmtion, be able to delete user or to reset 2FA)....

Originally created by @mtettke123 on GitHub (Jul 29, 2022). As most self-hosted installation will probably have registrations disabled, a admin interface to add/delete users would be VERY cool. Something like vaultwarden has (invite user, see user list, see space consupmtion, be able to delete user or to reset 2FA)....
Author
Owner

@kolaente commented on GitHub (Jul 31, 2022):

This is actually already a feature of the managed service. A possible way would be to extend this to self-hosters but given this is most useful to companies I'd like to keep this a paid feature to ensure the sustainability of the project.

@kolaente commented on GitHub (Jul 31, 2022): This is actually already a feature of [the managed service](https://vikunja.cloud/managed-service). A possible way would be to extend this to self-hosters but given this is most useful to companies I'd like to keep this a paid feature to ensure the sustainability of the project.
Author
Owner

@mtettke123 commented on GitHub (Aug 1, 2022):

Ah, I completely understand this, we all need money :-)

Maybe there's a chance for a simplified admin IF someday (maybe just userlist, inviting and deleting)?

@mtettke123 commented on GitHub (Aug 1, 2022): Ah, I completely understand this, we all need money :-) Maybe there's a chance for a simplified admin IF someday (maybe just userlist, inviting and deleting)?
Author
Owner

@Freundschaft commented on GitHub (Feb 9, 2023):

would there also be an option to buy this functionality as a paid plugin but used on a self-hosted instance? wed like to keep our data on our data centers, but would be happy to pay for such a functionality.

@Freundschaft commented on GitHub (Feb 9, 2023): would there also be an option to buy this functionality as a paid plugin but used on a self-hosted instance? wed like to keep our data on our data centers, but would be happy to pay for such a functionality.
Author
Owner

@kolaente commented on GitHub (Feb 9, 2023):

@Freundschaft We have a limited development version of that which I could offer you, shoot me a mail at konrad@vikunja.io if you're interested.

@kolaente commented on GitHub (Feb 9, 2023): @Freundschaft We have a limited development version of that which I could offer you, shoot me a mail at konrad@vikunja.io if you're interested.
Author
Owner

@4g0tt3nSou1 commented on GitHub (Jan 16, 2026):

Sorry to necro. Administrative features are almost essential to the self-hosting schema. If the instance is publicly exposed, I'm for project sustainability, and needless to say, I think this is a very neat project and a very fair option for people to use, but ensuring you have an idea of what users exist and, if need be, disabling access is pretty critical.

May I suggest that, ultimately speaking,g some sort of mechanic blocking user registration be at the very minimum implemented, and a basic panel for inviting users be instated? I'm not talking full functionality, but at a very minimum, the add/remove users, and block users from registering seems very critical.

Some of this can probably be done by watching the DB itself/etc, but who knows what kind of weird dangerous things someone random might accomplish and wreck, or discover.

From something that anyone can host for free, I don't want to ask for a golden egg, but I do think it is worth reconsidering implementing basic admin features.

@4g0tt3nSou1 commented on GitHub (Jan 16, 2026): Sorry to necro. Administrative features are almost essential to the self-hosting schema. If the instance is publicly exposed, I'm for project sustainability, and needless to say, I think this is a very neat project and a very fair option for people to use, but ensuring you have an idea of what users exist and, if need be, disabling access is pretty critical. May I suggest that, ultimately speaking,g some sort of mechanic blocking user registration be at the very minimum implemented, and a basic panel for inviting users be instated? I'm not talking full functionality, but at a very minimum, the add/remove users, and block users from registering seems very critical. Some of this can probably be done by watching the DB itself/etc, but who knows what kind of weird dangerous things someone random might accomplish and wreck, or discover. From something that anyone can host for free, I don't want to ask for a golden egg, but I do think it is worth reconsidering implementing basic admin features.
Author
Owner

@kolaente commented on GitHub (Jan 16, 2026):

You can disable the registration in the config: https://vikunja.io/docs/config-options/#1-service-enableregistration

More basic admin features exist via the cli: https://vikunja.io/docs/cli/

For anything else regarding users, I'd recommend using an external auth provider like Authentik.

@kolaente commented on GitHub (Jan 16, 2026): You can disable the registration in the config: https://vikunja.io/docs/config-options/#1-service-enableregistration More basic admin features exist via the cli: https://vikunja.io/docs/cli/ For anything else regarding users, I'd recommend using an external auth provider like Authentik.
Author
Owner

@4g0tt3nSou1 commented on GitHub (Jan 16, 2026):

Ah, very fair. I do agree with @Freundschaft here

would there also be an option to buy this functionality as a paid plugin but used on a self-hosted instance? wed like to keep our data on our data centers, but would be happy to pay for such a functionality.

In terms of sustainability, I get trying to make sure things are sustainable, I will say it is a slippery slope, that is why I avoided Leantime and Planka, but something like this makes lots of sense to have available as a "buy me a coffee/help keep the project alive" kinda addon.

@4g0tt3nSou1 commented on GitHub (Jan 16, 2026): Ah, very fair. I do agree with @Freundschaft here > would there also be an option to buy this functionality as a paid plugin but used on a self-hosted instance? wed like to keep our data on our data centers, but would be happy to pay for such a functionality. In terms of sustainability, I get trying to make sure things are sustainable, I will say it is a slippery slope, that is why I avoided Leantime and Planka, but something like this makes lots of sense to have available as a "buy me a coffee/help keep the project alive" kinda addon.
Author
Owner

@flyingnight commented on GitHub (Mar 2, 2026):

I tried to delete the user manually, and it prompted that there is no such user, but I can still see it when I use 'user list'

docker exec -it Vikunja /app/vikunja/vikunja user delete 2 --now
2026/03/02 14:22:19 failed to create modcache index dir: mkdir /.cache: permission denied
time=2026-03-02T14:22:19.048+08:00 level=INFO msg="No config file found, using default or config from environment variables."
time=2026-03-02T14:22:19.049+08:00 level=INFO msg="Running migrations…"
time=2026-03-02T14:22:19.084+08:00 level=INFO msg="Ran all migrations successfully."
You requested to delete the user immediately. Are you sure?
To confirm, please type "yes, I confirm" in all uppercase:
YES, I CONFIRM
time=2026-03-02T14:22:28.750+08:00 level=ERROR msg="Error removing the user: User does not exist [user id: 2]"

@flyingnight commented on GitHub (Mar 2, 2026): I tried to delete the user manually, and it prompted that there is no such user, but I can still see it when I use 'user list' > docker exec -it Vikunja /app/vikunja/vikunja user delete 2 --now >2026/03/02 14:22:19 failed to create modcache index dir: mkdir /.cache: permission denied >time=2026-03-02T14:22:19.048+08:00 level=INFO msg="No config file found, using default or config from environment variables." >time=2026-03-02T14:22:19.049+08:00 level=INFO msg="Running migrations…" >time=2026-03-02T14:22:19.084+08:00 level=INFO msg="Ran all migrations successfully." >You requested to delete the user immediately. Are you sure? >To confirm, please type "yes, I confirm" in all uppercase: >YES, I CONFIRM >time=2026-03-02T14:22:28.750+08:00 level=ERROR msg="Error removing the user: User does not exist [user id: 2]"
Author
Owner

@Joacbe commented on GitHub (Mar 19, 2026):

Very same behavior, trying to delete a user that is said existing (vikunja user list) but after putting in the confirmation message, I get a : time=2026-03-19T15:21:32.219Z level=ERROR msg="Error removing the user: User does not exist [user id: 5]"
Used to be working in the previous version of the app I was using (I updated a couple of weeks ago to 2.1.0)

@Joacbe commented on GitHub (Mar 19, 2026): Very same behavior, trying to delete a user that is said existing (vikunja user list) but after putting in the confirmation message, I get a : time=2026-03-19T15:21:32.219Z level=ERROR msg="Error removing the user: User does not exist [user id: 5]" Used to be working in the previous version of the app I was using (I updated a couple of weeks ago to 2.1.0)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#1791