How to create a new user account, without the CLI, in a ‘Registration disabled’ setup?
I couldn’t find any option in the API documentation to create a new account.
The /register endpoint doesn’t work either. Gives a 404 Error
If you disabled user registration you won’t be able to register a user via the api, you’ll need the cli. Disabling the registration essentially disabled the endpoint.
Why don’t you have access to the cli?
Well, the question is, why would i (the Server administrator) or any standard user, need to use the CLI for such a simple thing as adding new users?
I thought at least there would be an option in the API, to allow for manual adding of users, so that i (admin) can then create a frontend interface somewhere to manage the users. But even that’s missing, while all other, user-related endpoints are there.
Morever, having only CLI option forces the Server administrator to be the only one who can create new users!
Why?
This is a really weird and restrictive design choice.
I was looking around with a similar question the other day, and as far as I know (correct me if I’m wrong) it’s a “premium” feature for the cloud-hosted/paid version.
1 Like
Basically, we didn’t see the need to do this yet - either your instance is publicly open and everyone can register or you’re using oauth to manage users.
As @Mario correctly pointed out, there is an admin ui available as part of the enterprise offering.
To be honest, the admin ui only for Enterprise is a bit absurd.
Really? Most self-hosters are keeping their instances open to public?
Why is that absurd? (honestly interested in your opinion)
My reasoning is as follows: When you need an admin ui to manage users, you’re a) a company with many users and requirements for onboarding etc. or b) have a central authentication with oauth already anyway to manage users and thus won’t manage users in Vikunja.
Most self-hosters have a handful of users at most and don’t often add or remove users. In these cases they either quickly create a new user via the cli or open registration for a short window, register the new user and disable it again.
I considered this to be a rather odd choice, too, to be honest. I’d typically expect stuff like OpenID or other forms of remote authentication endpoints to be more corporate/pro user oriented than a simple web form (in a web program). Same for raw CLI usage. While you typically need CLI stuff to set up the server etc. don’t forget just running docker compose up -d is way more simple than actually understanding how to execute tools inside the image and to actually do so.
And while talking about the CLI being aimed towards pro users: Why am I forced to set a password creating accounts instead of just automatically mailing new accounts so they could set their own password right from the get-go? In my case, I set up all accounts with a throwaway password, then forced everyone to reset their passwords, which was like an unnecessary step, don’t you think?
1 Like
Really not true.
Self-hosters could be hobbyists, open-source enthusiasts, solo devs (single-user, handful of users, hosting for friends & family: 1-20+ users), indie hackers (upto 100 users), startups & small businesses (upto around 100 users).
And these groups usually account for a significant portion of users for such apps, if not the majority.
None of these fit the bill for being ‘enterprise users’, which would necessitate the need for external auth management solutions.
But what really irks me here, is the fact ( chicanery ?) that all the user-related API endpoints have been made publicly available, except for the primary one: creating new users.
This really speaks to the level of insincerity here.
You don’t wish to provide a free Admin UI, sure, no problem. But you even deliberately add exponential, systematic inconvenience to devs being able to freely create the full Admin UI, for an “open-source, self-hostable” app, i would consider that to be a rather cheap move.
Btw. for context, I’m also falling into this small business category with 10-20 users for now, for personal stuff I just use Google Keep or Microsoft’s To-Do (formerly Wunderlist).
Can’t deny that the lack of a user web UI and the missing API feel like an odd move now that I know the feature actually is in the cloud-hosted offer and me considering it a basic/core feature.
I can totally understand the need for some extra features to make the offer more interesting, but I also think this might be the wrong approach perception wise (apart from being a rather bland/weak selling point). This is a bit like other similar projects allowing you to host the tool for free, but then hiding Kanban boards and calendars behind a paywall (although on a completely different level).
I’m pretty sure there are not yet existing additions fitting this role of a selling point way more perfectly, especially in a corporate setting, that aren’t something non-techy people would want to use on a day to day basis.
For example, how about an inbox feature with filters? Users can set a POP3 (or IMAP?) account, where incoming mails are retrieved on a schedule. If recipients, subjects, or contents fit a certain pattern (could probably be set with a few regular expressions of sorts), a new task is created based on this information. In a similar way, tasks could be moved or marked as completed (to spin this idea further). This can be implemented using the API, but the cloud-service could offer it out of the box, exclusively.
Also I’ve seen others mentioning how they embed Vikunja into presentation websites to be shown on screens or billboards. A “presentation mode” like this for projects would be a very nifty pro feature many more casual users wouldn’t miss (and it’s not a core element by far). Power users could still implement something on their own and businesses not wanting to bother could just pay directly. Also spinning this idea a bit further, I could also imagine similar screens for things like Alexa or Google Assistant (don’t ask me how complex doing so would be, just throwing this out there) only connecting to the cloud version.
1 Like
I’m a rather new user, still want to give my 2 cent - while I can understand the frustration to not have any user creation endpoint, there’s a few more things that come with it - a proper RBAC concept for example. As far as I can tell permissions are done on a project level, but there’s no such thing as admin users as of today.
So that being said, for very small installations (some examples given above, solo devs, small groups), creating users via CLI may not be as convenient as it could be, but it works. For anything larger than 10 users, I’d probably expect there to be some centralised user management anyway, in which case I’d hope there to be some IDP. We use Keycloak, and the ability to use OpenID for user management and disable public user registration is really exactly what we need and wish for. It would be neat to have the ability to add users to Teams using OpenID, but this is actively being worked on.
In the end, the project is open source. If you want to have an API endpoint to add users - add it. That brings me back to the beginning of this post, it’s more than just the endpoint. Its roles, permissions and everything related to that - I’d assume the admin interface that’s part of the enterprise offering is a separate interface / instance, and not included in the product.
1 Like
IMHO you should be able to understand and use the tools you’re hosting at least a little bit. I know you won’t be able to understand everything in-depth, but as a self-hoster you are a sysadmin after all. If you’re afraid to run a simple, documented shell command you’ll have more problems later in your self-hosting journey.
Simply put, because that was not implemented. Again, if you have these requirements, it sounds like you’re better served by an application providing single-sign on whose only job it is to make the provisioning and management of users as simple as possible. Of course, I could implement all the bells and whistles of those applications into Vikunja, but I think there are other things with a higher priority. Especially since they already exist and probably do a better job than what I would build.
I was thinking about people hosting stuff for themselves or their families in my comment, but what you’re describing is of course also true. I personally know one-person self-hosted setups and big nonprofit organizations using Vikunja, both with an openid provider to manage their users. Maybe they’re not what one might consider “Enterprise” but they’re using it just fine.
I wouldn’t consider registration disabled if only the buttons in the UI were hidden but the api endpoint still available. What would you think if you’d disable registration on your instance only to discover someone who read the api docs and has a shell with curl could still register on your instance?
Of course, one could solve this with a roles system with instance admins, but then you’d need a way to manage those roles, circling back to the admin panel. This is not a technical problem.
In my opinion, it is fair to charge for added value like an admin panel or other things, especially if you’re a business making money with the help of Vikunja. Especially since the majority of users will be happy users of the Free (as in software) version and never pay at all. And that’s completely fine.
From the feedback I get so far, people are happy users of Vikunja. They already get value from it, without me collecting money for it.
There are countless examples of funding FOSS through donations only will not work if you’re not a well-known public figure (like Caleb Porzio) or a very large Open-Source project which has been around for decades (like curl).
I’m still figuring out ways for Vikunja to make money. One of those is the admin panel or other features like the ones you’re proposing (In fact, I have a whole list). The admin panel is just part of it. I know the problem of hiding these behind pricey Enterprise plans, effectively shutting out all self-hosters which are not a huge Enterprise with deep pockets. I don’t have a good solution for this, but I am thinking about it and you’ll hear about it when I have a better idea. If you have more ideas about this, please tell me (either by mail or DM or a forum post).
At some point in the next year I’ll have to make a choice: Either I work on Vikunja full time, and keep the project going and am able to develop it further, add new features etc. Or step down, only doing maintenance rarely when I have the time, not doing much.
I’ll have to make that choice because I need to pay my bills somehow. Right now I’m working just enough and am still studying so luckily, I don’t have to make that choice now.
If Vikunja should be able to pay me a salary, it needs to make money with what it’s offering. I’ve been exploring ways to do that with Vikunja cloud and the admin panel (though I haven’t really been marketing the latter, as I wouldn’t consider it “done” yet).
This is exactly what I mean 