I am getting the following error message when trying to disable a guest user inside a Cloud Code method.
Error: Status change for guest user is not allowed. Convert him to "regular" user first.
The error itself is pretty self-explanatory, I understand what is happening and what I would need to do.
Instead of
I would need to do
However, I find it quite strange for several reasons :
If some error happens somewhere in the process before it is really Disabled, I could end up with a user in the Enabled status, which doesn’t make sense.
It requires an additional API call, which adds server load and slows things down.
Unless I am mistaken, going from a Guest user to an Enabled user requires that I provide an email address beforehand (email is my identity). So it’s going to be still another API call.
Couldn’t it just be possible to simply disable the user, whether in Guest or Enabled status ? I don’t understand the limitation in having to enable first before disabling.
Actually, it’s worse than I thought : the first block (“Set user status as Enabled for user with id”) produces the same error. So I actually have to fully register the user before disabling him. It doesn’t make sense to me
The ticket you are referring to is not the same issue. For some reason, users had converted from guest users to full users but did not have the Authenticated User role when logged in. Instead, they were still showing the Guest User role.
Here, the question is that I cannot disable a guest user anymore. I am quite sure it used to be possible, and as you say, the fix for the previous ticket may have broken this behavior. I just did not notice it immediately and I now realize that over the past weeks several processes have failed following the mentioned fix.
The way I see it, it should be possible to change the status of users : Guest → Enabled Guest → Disabled Enabled → Disabled Disabled → Enabled
And whenever a user has a status of Guest, their roles list should include Guest User, and similarly, when a user has a status of Enabled, their roles list should include Authenticated User.
guest user may have stub in the fields, like email and so on, so in most cases it is not enough to change the status. So the only way to convert the user is to use API to convert the user Guest Login API - Backendless REST API Documentation. If you need some utility to convert, you may create a service in cloud and use it to convert guest user
Agreed, it makes sense for the Guest → Enabled change.
However, for Guest → Disabled, this shouldn’t be a problem, would it ? It just feels unnecessary to actually have to register the user with an email address that I have to invent, and a random password just the same, only to disable the user right after…
why not just delete the user? If you use DISABLED property as a kind of Blacklist so that some guest user cannot work with the application, then this does not guarantee that the user will log in from another guest account. Would deleting a user solve the problem?
Actually I am doing some king of soft delete. Indeed I am not using this as a blacklist: I am not looking for the user to be forbidden from logging in with another account, guest or not, on the contrary ! Instead of completely removing the user, I am keeping it in the database for statistical purposes, and because the user is linked to other objects created in other tables. Since there is a disabled state, I simply want the user to have that status.
But I have had to change my logic to something more complicated than before : I have to do Guest → Enabled → Disabled. And for the first step, I actually have to register the user with a valid email and a password.
In this case, perhaps it makes sense to use a custom column instead of the system one? For example, create your own “status” column and change its value (in this case, the system will not restrict you in any way). Of course, additional logic may be required to prevent regular users from changing this column, but this can be easily done using an event handler.
