Kolibri: "resources to be updated" diff count does not match reported import behavior and final count

[indirectlylit]

Observed behavior

observed by @radinamatic in https://github.com/learningequality/kolibri/issues/6280

• 23 resources initially imported
• diff reports 6 resources to be updated and 17 deleted
• task manager reports 10 resources updated
• final count reported on device is 12

|initial import| diff page | task page | on device summary |
|--|--|--|--|
| | | ||

Expected behavior

counts should add up

User-facing consequences

confusion about actual behavior

Steps to reproduce

update a channel with some content already imported

Context

• Kolibri version: 0.13.0b5
• Operating system: Ubuntu 16.04
• Browser: Firefox & Chrome

[ivanistheone]

There appears to be a whole cluster of issues around the channel update tasks, related to what has changed between channel versions (metadata diff between two DBs) and also counts of files that are available on device or have been removed. I propose we linked all the cluster of related issues to this one to make them easier to track.

Here is another issue related to counts of new items available: https://github.com/learningequality/kolibri/issues/6230 (different part of the UI, but I believe comes from the same backend logic)

[ivanistheone]

One aspect of the "what has changed" logic I run into on a weekly basis, is that content nodes for which the files have not changed are not marked as updatable (checkbox is checked, presumably because file is already available on device).

This makes it impossible to use the UPDATE feature for certain types of changes (metadata-only changes like fixes to titles, descriptions, and thumbnails).

• Workaround 1: using inspect tool in browser, locate the IMPORT button and manually remove the disabled=disabled attribute, then IMPORT becomes clickable, and updated channel can be downloaded.
• Workaround 2: delete the channel and re-import from clean slate.

This issue affects only Kolibri users who actively work on new channel creation/iteration, so probably not a lot of people, but if "what has changed" logic will be revisited as part of these issues, I'd recommend metadata-only changes be included as criteria for "node has changes" (provided computational cost is not prohibitive of course).

Implementation idea: perhaps we could compute some sort of "node hash" as part of the "what has changed" logic for each node, which includes title, description, files, assessmentmetadata, coach_content, parent_id?, sort_order?, author, tags, **license, and flag any nodes with differing "node hashes" as changed.

[benjaoming]

When aligning these summaries, it would be nice to also include the figures from Studio, which also differ. These figures take duplicate file sources into account.

The inverse of #6230 also shows a quite misleading figure. This makes an informed choice very difficult in cases with metadata updates. In this example, no file references have changed, hence no downloads will be triggered -- only meta data was changed.

vs.

[ivanistheone]

I just checked with Richard, and

Workaround 2: delete the channel and re-import from clean slate.

is "quiz- and lesson-safe", meaning if a user deletes a channel and immediately afterward re-imports (to get the new thumbnails) any lessons/quizzes will still work as expected (the quiz/lesson data is stored as json so not database-cascade-delete occurs).

One caveat is to not be editing quizzes/lessons while the delete-and-reimport tasks are running.

We can therefore recommend this as the official workaround until issue is fixed + for Kolibri servers that are running the old version cc: @jeepurs @radinamatic

[indirectlylit]

@rtibbles

due to a deliberate decision to leave this unfixed until we can clarify duplicate vs unique resources in interface strings

do we need new strings for this?

[rtibbles]

Yes, will do.