REST - Deleting Sub-Accounts

[kurt_faulknerlo]

Hello,

I've been doing some integration testing with the Canvas REST API and noticed that you cannot delete accounts/sub-accounts using the REST API.  While not a big deal for production purposes (we don't have a use case that would require deleting accounts using REST), it does make automated testing for creating/updating/deleting accounts & sub-accounts impossible.

That said, I can log into the server and manually delete sub-accounts just fine.  However, I've noticed that if I create a sub-account using an SIS_Account_ID, I'm unable to re-create the same sub-account.

Here's the JSON returned after creating the sub-account:

{"id":11,"name":"Test Sub Account","workflow_state":"active","parent_account_id":1,"root_account_id":1,"default_storage_quota_mb":500,"default_user_storage_quota_mb":50,"default_group_storage_quota_mb":50,"default_time_zone":"America/Los_Angeles","sis_account_id":"TST-11111","sis_import_id":null,"integration_id":null}

After logging into Canvas and manually deleting the sub-account, if I try to re-create the same sub-account, this is what I get:

{"errors":{"sis_source_id":[{"attribute":"sis_source_id","type":"SIS ID \"TST-11111\" is already in use","message":"SIS ID \"TST-11111\" is already in use"}]}}

This error doesn't occur if I don't use an SIS_Account_ID - I can create/delete/recreate accounts just fine.

Since I'm still very new to Canvas, I was wondering if anyone could provide (or point me to) more information about why Canvas behaves this way.  Since Canvas seems to hold onto the SIS_Account_ID, even after the Account using the SIS_Account_ID has been deleted, I'm thinking that either there's something important about the SIS_Account_ID that I'm not aware of - or this is some sort of bug - and we've got orphaned data hanging around in the database.

Thank you. 

[kurt_faulknerlo · Accepted solution]

After working with sub-accounts a little while longer, I think I can answer my own question.  I noticed that after the sub-accounts get manually deleted, their workflow_state parameter is changed to from "active" to "deleted".  Now things begin to make sense!  I suppose this is why there is no "delete" functionality for accounts/sub-accounts - they are never are actually deleted - they are only marked as deleted!

This behavior explains why sub-accounts created without an sis_account_id seem to be re-created and why sub-accounts created with an sis_account_id cannot be re-created.  That is, sub-accounts that have been deleted do not get re-created - it is actually a new account with the same name that gets created.  For sub-accounts created with an sis_account_id parameter, this parameter must (rightfully) be treated as a unique identifier, preventing a new account from being created with the same sis_account_id.  You can even use REST to update accounts that have been manually deleted.

I'm still not certain why you can't delete sub-accounts...  Anyone have any insight on this?