Deleting sessions completely

[ywarnier]

Current behavior

When deleting a session, the SessionManager::delete() method is used. However, this method only deletes session registers from access_url*, extra_field* and session_rel* tables. There is no management of the track_e_* tables nor all the c_* tables.
Deleting a session should do a thorough clean-up to avoid leaving resources hanging.
To find the list of resources, do a --no-data dump of a Chamilo database and look for all *session_id or id_session fields. This below is a list from v1.9:

    $tables = [
        'track_course_ranking' => 'session_id',
        'track_e_access' => 'access_session_id',
        'track_e_attempt' => 'session_id',
        'track_e_attempt_recording' => 'session_id',
        'track_e_exercices' => 'session_id',
        'track_e_course_access' => 'session_id',
        'track_e_default' => 'session_id',
        'track_e_downloads' => 'down_session_id',
        'track_e_item_property' => 'session_id',
        'track_e_lastaccess' => 'access_session_id',
        'track_e_links' => 'links_session_id',
        'track_e_online' => 'session_id',
        'track_e_teacher_in_out' => 'session_id',
        'track_e_uploads' => 'upload_session_id',
        'c_item_property' => 'id_session',
        'c_announcement' => 'session_id',
        'c_attendance' => 'session_id',
        'c_blog' => 'session_id',
        'c_calendar_event' => 'session_id',
        'c_chat_connected' => 'session_id',
        'c_course_description' => 'session_id',
        'c_document' => 'session_id',
        'c_dropbox_file' => 'session_id',
        'c_dropbox_post' => 'session_id',
        'c_dropbox_category' => 'session_id',
        'c_forum_thread_qualify_log' => 'session_id',
        'c_forum_thread_qualify' => 'session_id',
        'c_forum_thread' => 'session_id',
        'c_forum_forum' => 'session_id',
        'c_forum_category' => 'session_id',
        'c_glossary' => 'session_id',
        'c_group_info' => 'session_id',
        'c_link' => 'session_id',
        'c_link_category' => 'session_id',
        'c_lp_view' => 'session_id',
        'c_lp' => 'session_id',
        'c_notebook' => 'session_id',
        'c_quiz_order' => 'session_id',
        'c_quiz' => 'session_id',
        'c_student_publication' => 'session_id',
        'c_survey_invitation' => 'session_id',
        'c_survey' => 'session_id',
        'c_thematic' => 'session_id',
        'c_tool_intro' => 'session_id',
        'c_tool' => 'session_id',
        'c_wiki_mailcue' => 'session_id',
        'c_wiki' => 'session_id',
        'gradebook_category' => 'session_id',
        'session_field_values' => 'session_id',
        'session_rel_course_rel_user_date' => 'session_id',
        'user_rel_course_vote' => 'session_id',
        'usergroup_rel_session' => 'session_id',
        'session_rel_course_rel_user' => 'id_session',
        'session_rel_course' => 'id_session',
        'session_rel_user' => 'id_session',
        'access_url_rel_session' => 'session_id',
        'session' => 'id',
    ];

(normally all id_session fields were transformed to session_id in 1.10).

It also should include the proper deleting, on disk, of session-specific documents, assignments, etc.

There is no rationale for leaving the data there. A session can be "expired and closed" in a way that does not get in the way of anyone, so no need to delete if we want to keep the data there. When a session is deleted, it's because we really want it to be deleted. If it's a mistake, then the admin should use backups to restore it.

Expected behavior

SessionManager::delete() should delete all resources related to the deleted session.

Steps to reproduce

• Create a session with a course (write down the session ID from the URL)
• Enter the course+session
• Create a document
• Go to admin > sessions list > delete session
• Select * from c_document where session_id = $id => there shouldn't be anything, but there is.
• Same thing with track_e_course_access, etc

Chamilo Version

1.11.x 20170621

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[christianbeeznest]

It is checked with this PR #6038 , it requires more testing to merge.