You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When another course's groups are on a folder, it creates a name collision the second time we attempt to create the group. Example:
Course B Creator has Viewer access to Course A
When we run course_folder(Course A) we create the group "Course B Creator (internal)"
Later, when we run course_folder(Course B) we fail when trying to create the same group
Panopto's SOAP API has no GetFolderByName method. So when we hit a collision, we can't get the ID of the group to add it to the appropriate role on the course folder currently being processed.
We could keep a { "Group Name": "Group ID" } hash of all groups we've created thus far in the script and consult that when there are collisions. Running at the term level with a semester string --filter this might work because the only groups being created are those for some course folder underneath the term.
There are probably too many user groups to download all their data using another method. I think there is a method to get the groups a user is in...maybe we could use that method with one of the group's members to try to find the pre-existing group when a collision happens?
The text was updated successfully, but these errors were encountered:
Another approach would be to append a short hash of the original group name and the folder name to the end of the internal group name so we would have unique names per course folder.
When another course's groups are on a folder, it creates a name collision the second time we attempt to create the group. Example:
course_folder(Course A)
we create the group "Course B Creator (internal)"course_folder(Course B)
we fail when trying to create the same groupPanopto's SOAP API has no
GetFolderByName
method. So when we hit a collision, we can't get the ID of the group to add it to the appropriate role on the course folder currently being processed.We could keep a
{ "Group Name": "Group ID" }
hash of all groups we've created thus far in the script and consult that when there are collisions. Running at the term level with a semester string--filter
this might work because the only groups being created are those for some course folder underneath the term.There are probably too many user groups to download all their data using another method. I think there is a method to get the groups a user is in...maybe we could use that method with one of the group's members to try to find the pre-existing group when a collision happens?
The text was updated successfully, but these errors were encountered: