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?
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
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.
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.
@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 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.
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.
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:
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.