Potential for duplicate resource identifiers (Pages visualization)

[jlongland]

We received feedback from a pilot instructor that Canvas wiki page views would be more useful than file views for the Resources Accessed dashboard in their course. It makes sense given that the bulk of their content is in pages. I decided that I would add an additional query to RESOURCE_ACCESS_CONFIG. There's a slight issue with this given that Canvas Live Events lack the attributes to generate a link to the resource (and uses a different pattern than files). I was going to workaround this by passing an empty string from views.py for the URL (and look at a better solution in the future).

But as I was testing, I realized that the resource.resource_id is populated with whatever identifier is provided in the query of the source learning tool. Not ideal when loading resources from multiple source learning tools. I suppose the odds of an identifier collision are low when the source tools are likely using different identifier formats? But when we’re loading resources from the same source that use the same pattern for identifiers (e.g. bigint in the case of Canvas) it seems like we run the risk of an identifier collision? Which seems like an issue given the constraint on the model.

So I checked our data and it looks like this will be a problem:

select count(*)
from file_dim
join wiki_page_dim 
on file_dim.id = wiki_page_dim.id

1330848 rows

I was just wondering if this has come up in any previous discussions? I searched issues but didn't come across anything about this specifically. I was wondering if it would make sense to have a generated resource.id and a resource.source_id?

[jlongland]

@jennlove-um I'm not sure this is necessarily an enhancement? The potential for identifier collision feels like more of a bug. If two source learning tools are using the same approach for identifiers (ex. big integer), there will be an identifier collision.

My inclination is that there should be a MyLA resource identifier as resource.id and the identifier from source learning tools should be something like resource.source_id But it's possible I'm misunderstanding the situation here. Curious if @jonespm or @zqian have comments?

[zqian]

@jlongland sorry we did not reply earlier. This is a valid concern for id collision. We did not have the problem here in UM because we are not including the wiki usage data.

Somehow, I think we can solve this problem with existing db schema: we just need to use different value for resource_type field in the MyLA resource table.

Currently, the resource_type is set to "canvas" for Canvas files. We can use "canvas" for Canvas file record, and "canvas_pages" for wiki page, etc. WDYT?

[jennlove-um]

For the Resources Accessed view, we would also need to add the filter for the type "Canvas pages" to differentiate them from the files and videos. We will also need to identify an icon for the pages to differentiate them.

[jennlove-um]

The display should be limited in Resources Accessed to show only pages that are accessible to students. Pages that are accessed by teachers only should not be included. For example, pages that are not published should not be included in the view.

[zqian]

The need of "reporting only the student-initiated page access events" will be handled by #764 , alongside with the data types of resource access and video access. So I would suggest we focus on the "Pages view" event query for this issue. @jonespm and @jennlove-um ?

[jennlove-um]

From a functional point of view, I'm only concerned that both issues get done so that only student events are displayed in the view. So whichever way it makes sense to do the coding is fine with me.

[jennlove-um]

Pages are displayed in the Resources Accessed in testing in Beta. Testing for this issue passes.

Note: Mivideo events are not there, but for the moment, that appears to be a separate issue.

[jennlove-um]

Testing passes in beta for the MyLA 2022.01.03 release.

[jennlove-um]

Testing passes in test for the MyLA 2022.01.03 release.