ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.

Ability to automate user deactivation at workspace level (API)

Idea ID 2778321

Ability to automate user deactivation at workspace level (API)

We have a policy to deactivate users at workspace level when

(1) Project is completed

(2) When users have not accessed the workspace in 45 days (internal operational process)

 

We currently have a manual process to deactivate these users on a monthly basis one-by-one. Currently, we do this for hundreds of users every month and it is time intensive and prone to human error.

 

We are looking for an API that can deactivate users at the workspace level so that we can automate the process. Deactivate at space level is not sufficient as we have hundreds of workspaces within a space. It is possible that a user may have access to multiple workspaces within a space and thus they must remain active at space level so that they can access the workspaces/projects that are still active, but no longer access a workspace/project that is complete.

2 Comments
Micro Focus Contributor
Micro Focus Contributor

Hi,

In order to do that, you need to update the field "ws_user_activation_status" in "workspace_user" entity to 1.(and back to zero if you  want to activate the user again).

However, update operation on "workspace_user" entity is not part of our officially supported public API. (although it should be in the future)
As a temporary solution you can indicate specifically in the header of the request that you want to use a private API. (which is not supported officially, but in this specific case it should work fine)

There are two ways to do that:

If your octane version is 15.0.46 or above, you can put the following header in the put request:
ALM-OCTANE-PRIVATE: true

If you are using older version of octane, add the following header to the request:
HPECLIENTTYPE: HPE_REST_API_TECH_PREVIEW
(if you already using this header with another client type, replace it with this header)

The results are the same for both headers, but the second header, is planned to be deprecated in future versions.

example of fetch request using the first header:

fetch("http://localhost:8080/api/shared_spaces/1001/workspaces/1002/workspace_users", {
    "headers": {
          "accept": "application/json, text/plain, */*",
          "content-type": "application/json;charset=UTF-8",
          "ALM-OCTANE-PRIVATE": true,
          "timezoneoffset": "-180",
           "xsrf-header": "xxx"
   },
   "body": "{\"data\":[{\"ws_user_activation_status\":1,\"id\":\"1002\"},{\"ws_user_activation_status\":1,\"id\":\"1003\"}]}",
   "method": "PUT",
});


Regards,
Eli Emanuel, Octane R&D

Micro Focus Expert
Micro Focus Expert
Status changed to: Accepted
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.