When creating a new user via the api, no role is assigned to the new user.
Send the api call:
POST /_/users HTTP/1.1
Host: mydirectusdomain.tld
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Authorization: Bearer eyJ0eXAiOiJ0aCIsImtleFULLVALIDTOKENNDkyZTVhZiOiJfIn0.9E7AcoPfMAw5vrb3M9AMHjToDqcPbPBJf8GF6qG
cache-control: no-cache
Content-Disposition: form-data; name="email"
[email protected]
Content-Disposition: form-data; name="password"
validpw
Content-Disposition: form-data; name="email_notifications"
1
Content-Disposition: form-data; name="first_name"
Test
Content-Disposition: form-data; name="last_name"
Test
Content-Disposition: form-data; name="status"
active
One or both of the following:
1) User should be assigned to some default user role (perhaps defined in global settings)
2) User role should be assignable when making the [project]/users api call
User is created in the db but is not associated with a role.
I'm not sure I would call this a bugβit's more of an enhancement that's been discussed before, that will allow you to create users with roles.
The important question is: _can_ you set a role when creating a user through the API? Does it need to be an additional call?
Going by my understanding:
I believe it's an additional call to the roles table when authenticated with the correct privilege for that table. Eg; an admin would make two calls, create the user, then add the user to the role.
There's not really any concept of a "default role" as far as I'm aware, which is where this would become an enhancement, by potentially allowing the setting of a default role.
You can assign and even create a role through the api directly when creating a use. User to roles is nothing different from a regular M2M and works the same way when posting an item.
OK, I've added a ticket to the Docs repo where we can further explain this with an example.
Do we want to keep this one open and add a "default" role for users? Should the user's role be optional or required?
Should the user's role be optional or required?
Good question, a user without a status is also locked out of the system which makes it act like inactive.
A little more reasoning for why I thought this was a bug:
The user can be created via the Public api. But using that public api you cannot add a role bc that would allow you to create an admin. So you end up with a user with no role, which to @rijkvanzanten 's point is an effectively inactive user.
_Just throwing an idea out there_
Could you add a user to the public role?..
I was thinking the system could add new users to public by default (so they have a role assigned), and create a setting for "default role", where an admin can select the registration role if they want anything other than...
Hey @zeusstl β this would work fine if you create the user with an actual token (instead of public).
To me, the idea of opening up creating non-public roles from a public endpoint doesn't fit our 80/20 rule. It also seems rather unsafe β so I'd say the best way to accomplish this would be to build your own user/member collection on top of Directus.
I'm fine with adding the option for choosing a default group for new users though, so let's start with that. :)
The question of registering new users from the outside is a feature that has been asked about before a couple times already. As of right now, you can open up create for directus_users for a specific status.
asked about before a couple times already.
Is an understatement if you look in the Slack π
π¬
Can we come up with a way where we can lock of particular roles in the O2M from directus_users based on the status? We can already lock the status one can create from a public role π€
If we have a way to add field validation based on the status, we can force users into a particular role when created from the public group.
@benhaynes @shealavington
Honestly, I've read your comment ten times and I still can't wrap my head around it, @rijkvanzanten.
π
Just curious, isn't allowing admins to set a default group for new users the easiest and safest option? By default this could even be the public role since it would be the least permissive.
I also didn't understand that Rijk π
Consider this: on registration, users get to pick red team or blue team. These are two roles, which users should be allowed to "self-assign" to when registering.
Understandably, Directus isn't built around providing a user system, however there seems to be a demand for allowing users to select a role on registration.
Could we put up a poll (somehow) with a variety of options with potential enhancements for the user system?
Alternatively, we could keep things as they are, but just build one custom endpoint that can be configured to allow users to register into role X, Y, or Z. Like a marketplace extension. "Member Registration"
_I feel like I always offer too many solutions without deciding on one myself_ π
There have indeed been a lot of people requesting "Register"... and you might have noticed I included a button for this in the new Login design! Ref: https://github.com/directus/app/issues/1525
I'd say we should plan on building this in as a core feature (off by default). Still, I don't think users should be able to _pick_ their role. We don't allow it for existing users on the User Detail page... so why allow it for new users?
I'd say the following should suffice:
public)Wait... I think this all already works..? You can open up create permissions for the public group, but put the status in the field write blacklist. This combined with the default value for status should be enough?
I think we should introduce the default role named User in addition to Administrator and Public. This can be used as the default for new user addition via API or from Directus App. Obviously, there won't be too many administrators while adding users to the system so default User role will be applied all the time while creating a user.
With this we can have a clear picture of a system divided into 3 parts:
Administrator: Does everything.
Users: Registered users. Have limited access to the system defined under this role. This will be helpful in cases where registration is public.
Public: Publically available data without registration.
Hmm, we _could_ add another included user role for user but I don't know about using it as a registration default. I think using public makes more sense since it's the least permissive. If you have a user signing up on a public page, giving them public access isn't that risky.
Again, we can add a "Choose your default user role" dropdown in Settings so that admins can override β but our default default should be the safest option.
Also, I've seen a lot of names for the "users" role (members, accounts, teachers, interns, staff, editors, etc)... so I don't know if we need to include one by default.
Apologies. Not closed - mistake.
To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.
This issue being closed does not mean it's not being considered.
In case anybody needs this. I managed to assign a user role with a hack by using a hook triggered when a user has been created:
<?php
use Directus\Database\SchemaService;
return [
'actions' => [
// This is a workaround to set roles on creation of a user. When creating a user through the api directus doesn't assign any role by default. No matter what your "roles" parameter says. That's why we end up with a user that can't login.
// To assign a role we now have to add "_role_" + any number to the first name. The script will automatically assign the role while preventing assigning the Administrator role (1). Don't worry, the first_name will also be corrected automatically.
'item.create.directus_users:after' => function (array $data) {
// get database connection
$ConnectionInstance = SchemaService::getConnectionInstance();
// check if first_name ends with "_role_" + any number
if (preg_match('/_role_\d+$/m', $data['first_name'])) {
preg_match('/\d+$/m', $data['first_name'], $matches);
$user_id = $data['id'];
$role_id = $matches[0];
// make sure user role is not 1
if ($matches[0] > 1) {
// fix the first_name by removing the _role_ + any number suffix
$first_name = preg_replace('/_role_\d+$/m',"",$data['first_name']);
$ConnectionInstance->execute("UPDATE `directus_users` SET `first_name` = '$first_name' WHERE `id` = $user_id;");
// add entry in directus_user_roles table
$ConnectionInstance->execute("INSERT INTO `directus_user_roles`(`id`,`user`,`role`) VALUES (NULL,$user_id,$role_id);");
}
else {
// delete user
$ConnectionInstance->execute("DELETE FROM `directus_users` WHERE `id` = $user_id;");
// throw exception
throw new \Directus\Exception\UnprocessableEntityException('It\'s not allowed to assign the administrator role!');
}
}
}
]
];
Old thread, but I'm still curious...
Can't this be done by setting a default value on the role field? E.g. default to 2 for public role.
@buckhornmktg, yes that's totally possible. However, we historically haven't allowed users to change any of the field settings for the directus_ collections through the UI, so while that's possible by doing it directly in the DB, it isn't "officially" a thing in v8.
@rijkvanzanten, that makes sense.
I think we should introduce the default role named
Userin addition toAdministratorandPublic. This can be used as the default for new user addition via API or from Directus App. Obviously, there won't be too many administrators while adding users to the system so defaultUserrole will be applied all the time while creating a user.With this we can have a clear picture of a system divided into 3 parts:
Administrator: Does everything.
Users: Registered users. Have limited access to the system defined under this role. This will be helpful in cases where registration is public.
Public: Publically available data without registration.
the old way on doing this is to set the default value in database, thenset Public to able to create user., but disable the role rield. I'm not sure if its working as I imagine. But it should work.
Most helpful comment
There have indeed been a lot of people requesting "Register"... and you might have noticed I included a button for this in the new Login design! Ref: https://github.com/directus/app/issues/1525
I'd say we should plan on building this in as a core feature (off by default). Still, I don't think users should be able to _pick_ their role. We don't allow it for existing users on the User Detail page... so why allow it for new users?
I'd say the following should suffice:
public)