delete user via REST

André Lemberg shared this idea 21 days ago
In Progress

Hello, i tried to delete a user via REST.


Doc: https://developers.yellowfinbi.com/dev/api-docs/current/#operation/deleteUserAdmin

I get the return Code 200 but the User is still activ.


I would have expected the user to be deleted or set to inactive but in the Yellowfin (V9.8.0.1 Build 20221005) adminarea the user is still shown as active.


Does anyone have an idea why or am I thinking wrong?


Regards,

André

Replies (1)

photo
1

Hi André,

I hope you're well.

That command removes the user's access to all organisations, effectively disabling them. I believe this is a safety feature to avoid losing access to the content that user might have created.

However you can use the SOAP Api call DELUSER to carry out the task you're looking to do. https://wiki.yellowfinbi.com/display/yfcurrent/User+Replication+and+Management+Services

Kind regards,

Chris

photo
1

Hi Chris,

I'm fine, hope you're well too.

Thanks for your reply. I would like to edit the user administration as automated as possible via REST. Is there with REST also the possibility to set a user to inactive or to delete?

Kind regards,

André

photo
1

Hi André,

From what I can see, we don't have a documented REST capability for this feature. I can find out if one is implemented and if not, write an enhancement post so that we can see this feature in a future version of Yellowfin.

Kind regards,

Chris

photo
2

Hi Chris,

Isn't your REST API supposed to replace the old SOAP interface? I don't know anyone who plans to use 2 techniques permanently.


If I'm right, the functionality would be forgotten and then it would be a defect, wouldn't it?


If it is a defect, I hope for a faster fix. For us it is quite costly to implement a special way only for "delete" in user sync process


;) Stefan

photo
1

I'll get it confirmed with the product architect and let you know.

Regards,

Chris

photo
1

Hi André,

I just tested this yellowfinURL/api/admin/users/:userId command again and it appears to work for me.

For example, I have a test user created that has access to both the default org and a test org:

f5e1d71a446849677da519e1625f348b

9913eb2de87ec46b9624688e0dafb8f8

Using Postman, I delete the user using the userid as the parameter:

54434b7400ab1dec6487a61e2e69df3a

I refresh Yellowfin's Admin Console, the user is gone:

85b2881844054174c780a368b9895c33

They are removed from the client org:

ead41a7e627c792cf14ac7324b957c7c

and cannot be logged into.

This is in 9.8.1. I can check to see if this is the case in 9.8.0.1, however can you confirm that you used the same method as above?

Kind regards,

Chris

photo
1

Hello Chris,

we have found out that the documentation is incorrect. It says that you have to append the userid to the url but you have to take the ipid. Then it works so far that the user no longer appears in the interface of the admin console. But in the DB you can still find a lot of entries for the person and there it is still active.

Regards,

André

photo
1

Hi André,

I have been told that functionally, this REST API command calls the same as the SOAP one so they carry out the same process. The user will remain in the database so that linked content and mentions are not orphaned. In the ipclass table, an end date is added to the user. The ipid is just the name of the column in the database. It is technically referred to as the UserID.

Let me know if there's anything else around this topic you want to cover.

Kind regards,

Chris

photo
1

HI Chris,

Hi Chris,
I am working with Andre and the original question has been answered.

I would still like to know how to reactivate a "deleted" user. Currently you can't get to the user profiles data via REST and the user has to be recreated. Sounds ok, BUT the user loses all his settings if he was accidentally deleted/actually deactivated.

Is there a clean, defined API way to do this?

;) Stefan

photo
1

Hi Stefan,

At the moment, you can't recover a deleted user. There is a user status, whereby they can be set to 'INACTIVE' and then later you can reactivate them so that they aren't gone forever. However the kicker is that currently this cannot be done using the REST API.

We have an enhancement open currently for this capability, which you can take a look at over here: https://community.yellowfinbi.com/ticket/22902

If that sounds like something you want to see implemented in a future version of Yellowfin, go ahead and vote for the idea. More requests will help bring visibility to the development team and get it moved up their priority list.

Kind regards,

Chris

photo
1

Hi Chris,
sounds good, inactive first and clean up later.
Unfortunately, your link does not work, I get a 404. The good idea will not already be rejected, right?

;) Stefan

photo
1

[link removed to avoid confusion. This ticket is the public post for this enhancement request.]

photo
1

Hi Chris,

unfortunately no, again 404

;) Stefan

photo
1

Hi Stefan,

I'll make this the public Community post for this idea and have everything linked together.

Kind regards,

Chris

photo
1

Hi Chris,
I don't understand. Can I vote for the idea now? I still get a 404 error.

;) Stefan

photo
1

Hi Stefan,

You should be able to vote for this post instead. This one will serve as the public Idea post and everything will link back to this.

Kind regards,

Chris

photo
1

Hi Chris,

OK, I don't think it will work transparently for other customers. The question goes in a completely different direction and the text does not even contain the keyword "activate/deactivate users". So there will be no points and the "secret" idea will still not be seen and will simply go down. Probably not so good for the product.

Then let's close the question and keep the fake text running as an idea. We are curious ...
; Stefan

photo
1

Hi Stefan,

If you like, I can create a separate enhancement post under your name with just the relevant text, if that suits you better. Let me know.

Kind regards,

Chris

photo
1

Chris,
can't you just release the "secret" ticket? I myself have now also voted for something that I have not read in detail. From my point of view, this could generally run a little more transparently.

;) Stefan

photo
Leave a Comment
 
Attach a file