Migrate user_delete_request from Drupal

As part of the migration from Drupal 7, the user_delete_request feature will be added to the profile-api. This issue will be used as a place to generate discussion and gather requirements.

As I am still rather unfamiliar with this process/workflow, @cguindon is there a spec I can reference for this? Can you point me to where the current Drupal implementation is?

added Feature Request MBO prioritymedium statetodo team:webdev labels

assigned to @zacharysabourin

The Drupal implementation is here: https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/eclipse_api/-/blob/7.x-1.x/resources/user_delete_request.inc

However, I am realizing that it's missing an important part of the process.

To migrate this Java, we will actually need to implement an extra API call to register a deletion event. The drupal API currently only updates rows in a database that were created by the accounts.eclipse.org website.

@zacharysabourin Let's schedule a call together in the first week of Q2 to discuss this in more detail.

I will let you schedule the call. Just find a timeslot where I am currently available!

Here's how all of this works:

1. An Admin visit the edit form of a user on accounts.eclipse.org and click on the disable button to kick off the user deletion process:

https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/site_login/-/blob/7.x-4.x/site_login_accounts/form/site_login_accounts.user_profile.inc#L402

2. The account website then informs the User delete API that a user needs to be deleted:

This is done via /account/profile/:user_id/user_delete_request.

• https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/site_login/-/blob/7.x-4.x/site_login_accounts/form/site_login_accounts.user_profile.inc#L410
• https://git.eclipse.org/c/www.eclipse.org/eclipse.org-common.git/tree/classes/rest/userinformation.class.php#n103
• https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/eclipse_api/-/blob/7.x-1.x/eclipse_api.module#L1192

The implementation of that API call is here: https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/eclipse_api/-/blob/7.x-1.x/resources/profile.inc#L86

It basically:

1. insert a row per service in the api_eclipse_api_user_delete_request table.
2. insert a row in the account_request table to ask LLC to remove the user from ldap
3. anonymize the friend table

3. A cron job checks for new deletion requests

There is a cron job that queries our API and asks if there are any new deletion requests for each web service: https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/site_login/-/blob/7.x-4.x/includes/SiteLoginHelper.inc#L1663

https://git.eclipse.org/c/www.eclipse.org/eclipse.org-common.git/tree/classes/rest/userDeleteRequest.class.php#n51

If a user is found and deleted, we set the status to 1. If the user never existed on that site, we set the status to 2: https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/site_login/-/blob/7.x-4.x/includes/SiteLoginHelper.inc#L1698

The default status is 0 meaning that it wasen't been dealt with yet.

4. Cleanup

Once all the sites have reported that they've dealt with the request, we can clean up the api_eclipse_api_user_delete_request table:

https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/eclipse_api/-/blob/7.x-1.x/eclipse_api.cron.inc#L71

Note that in this implementation, we ensure that the last record should always be accounts.eclipse.org. You don't need to do that. We should be able to take care of that on the account website.

I will just need to be able to fetch a list of all records in the api_eclipse_api_user_delete_request table for a user. That should allow me to validate that all the other sites have been dealt with.

If so, the account website will ensure that the user was removed from LDAP and then remove from our accounts database. It will also take care of sending all the necessary emails.

added #38 (closed) as child task

added #39 (closed) as child task

added #40 (closed) as child task

added #41 (closed) as child task

added #42 (closed) as child task

added #43 (closed) as child task

added #44 (closed) as child task

mentioned in issue #50 (closed)

The DDL is here: https://gitlab.eclipse.org/eclipsefdn/it/websites/drupal/eclipse_api/-/blob/7.x-1.x/eclipse_api.install#L538

mentioned in issue #51 (closed)

added statewip label and removed statetodo label

mentioned in merge request !16 (merged)

added #54 (closed) as child task

mentioned in merge request !17 (merged)

added statereview label and removed statewip label

The user_delete_request endpoints are ready for sign-off!

The following endpoints are enabled and ready on staging:

• POST /sandbox/account/profile/{username}/user_delete_request
• GET /sandbox/account/user_delete_request?params...
• GET /sandbox/account/user_delete_request/{request_id}
• PUT /sandbox/account/user_delete_request/{request_id}
• DELETE /sandobox/account/user_delete_request/{request_id}

The OpenAPI spec

@cguindon I will schedule a call for later this week to go over this. Feel free to poke at these whenever you have the time and let me know what you think. Do not hesitate to bring up any questions or concerns.

I also had a conversation with @malowe today about signing off.

To make it easier for me to test and help other understand how we are expecting to use your API, I requested that he creates a sub-page of https://gitlab.eclipse.org/eclipsefdn/it/webdev/eclipsefdn-webdev-toolkit/-/wikis/Documentation/Devops/Example-of-oAuth2-dance-with-curl-and-accounts.eclipse.org with documentation on how to query the API using CURL.

I understand that most of this is in the spec and I will need to review that as well but the example is definitely useful for getting started with the testing.

I can also see the Drupal team wanting to view that page when they start using your new API.

It is still an annoyance that these open API spec still don't render in Gitlab.

Also, a reason why I am asking for curl commands is that we will probably need to test these APIs more than once before it's ready for prod. Having reproducible steps that we can copy and edit will help speed things up with the testing. Especially, if we consider that we have more than 1 of these APIs to test.

FWIW - The real signed-off will happen once we are done implementing this API with our Drupal sites.

For now, I can test to ensure I don't see any major issues or missing functionality which I will accept as good enough for completing the objective of this quarter's MBOs.

Sounds good to me! I've added to my list to update the wiki with the necessary curl commands

In the future, we should look for better ways for testing our APIs. Perhaps we could leverage tools such as POSTMAN which seems to allow for sharing tests with teams:

• https://www.udemy.com/course/api-testing-with-postman/
• https://learning.postman.com/docs/collaborating-in-postman/working-with-your-team/collaboration-overview/#:~:text=There%20are%20several%20ways%20you,redirected%20to%20your%20new%20team.

My concern with POSTMAN is that it's a subscription-based service.

I was about to ask about not doing CURL because it makes everything more complicated. Postman is a paid service, but Insomnia is free and does nearly identical things and is what I use to run tests. You can also export/import collections so we'd be able to share tests.

added statedone label and removed statereview label

closed

removed statedone label