Open NicoDucou opened 3 years ago
It think that I found the source of the problem.
All the incorrect registry in c_item_property have "lastedit_type = FolderUpdated" and "tool = document".
The "FolderUpdated" statement only appears for document in the restoration of a course process. So it means that when you export a course that contains folders that are attached to a group, then when you import it in a new course it gets imported to the new course but it gets also attached to the group_id.
So in this moment the wrong registry appears.
It's in the public function restore_documents in src/Chamilo/CourseBundle/Component/CourseCopy/CourseRestorer.php
api_item_property_update(
$course_info,
TOOL_DOCUMENT,
$documentData,
'FolderUpdated',
$insertUserId,
$groupInfo,
$toUserId,
null,
null,
$my_session_id
);
The problem is that if the course is restore in the same as the original for example when it serves has a backup for the course then it is usefull to have the same group assignation for documents and folders, but when a backup is restored in a new course (for example to do a copy or to reuse part of the content) then there is no need for the group assignation and it causes the problems.
I do not have a good solution for the moment but at least we probably know how it happens.
Since in Chamilo 2, the documents will not be limited to 1 course only and there is no more c_item_property table this might solve the issue so I do not know now that we anderstand the source of the problem if it woth trying to solve it in Chamilo 1.11.x
On a Chamilo 1.11.16 we could not delete groups inside a course. After analysis we found out that there were registry in c_item_property with this group as the to_group_id but a different c_id than the course where the group was created.
The problem is that in the deleteGroup function https://github.com/chamilo/chamilo-lms/blob/8196eb8e708add895229ac8c3a7688133f23da97/main/inc/lib/groupmanager.lib.php#L502 it only delete the registry in c_item_property for the c_id corresponding to the course.
So the others are kept and block deleting the group registery in the c_group_info table.
We did not find out how this happened for groups to be registered in c_item_property with a different c_id but to unlock the situation we delete all the registry in c_item_property that had to_group_id referencing the group which ever the c_id was.
To find all the c_item_property registries that have this problem you can use this query :
select ip.iid from c_item_property ip, c_group_info gi where ip.to_group_id = gi.iid and gi.c_id != ip.c_id;
And then delete all the registries corresponding.