ctsit / redcapcustodian

Simplified, automated data management on REDCap systems
Other
12 stars 6 forks source link

Write `delete_project()` function #138

Closed pbchase closed 8 months ago

pbchase commented 8 months ago

Write a function, delete_project(project_id) that implements REDCap's normal "soft deletion" as implemented in REDCap's ProjectGeneral/delete_project.php:

$sql = "update redcap_projects set date_deleted = '".NOW."'
         where project_id = $project_id and date_deleted is null";
...
ToDoList::updateTodoStatus($project_id, 'delete project','completed');
...
Logging::logEvent($sql,"redcap_projects","MANAGE",PROJECT_ID,"project_id = ".PROJECT_ID,"Delete project");

That said, we don't need a ToDo list entry for this, so only implement these two steps:

$sql = "update redcap_projects set date_deleted = '".NOW."'
         where project_id = $project_id and date_deleted is null";
...
Logging::logEvent($sql,"redcap_projects","MANAGE",PROJECT_ID,"project_id = ".PROJECT_ID,"Delete project");

Params

project_id should be a vector of REDCap project IDs

Tests the function perform

The code should verify:

If either test fails, note it in a status column and do nothing with the project ID. If the tests pass, delete it and note that in the status column.

Returns

The function should return a list of these objects:

Unit tests

Please add a testthat test to verify the code can:

To write that test, you will need a tiny redcap_projects table and one redcap_log_event table. Steal liberally from https://github.com/ctsit/rcc.billing/blob/main/tests/testthat/get_billable_candidates/make_test_data_for_get_billable_candidates.R to make that data. Steal from https://github.com/ctsit/rcc.billing/blob/main/tests/testthat/test-get_billable_candidates.R to use the test data you made with the previous script.

Ask @pbchase for help writing these tests if the examples seem obtuse.

For reference, this work was first discussed in https://github.com/ctsit/rcc.billing/issues/78

pbchase commented 8 months ago

I failed to mention important details about redcap_log_event tables. There used to be only one, named redcap_log_event. Now there are 9 such tables. They are enumerated in the package object redcapcustodian::log_event_tables. Each project's log records are in one and only one redcap_log_event table. That table is named in the redcap_projects table, though I don't recall the column name.

The function we are creating in this issue, delete_project() will need to read redcap_projects to get the log event table so it knows which redcap_log_event table to log to.

This has implications for the test data set. When I say "you will need a tiny redcap_projects table and one redcap_log_event table" I am saying you should make sure all of your test projects share the same redcap_log_event table. It simplifies your testing life if you force each project to use the same redcap_log_event table and then provide only that table for the function to write to.