At this points, there is no way to differentiate between Items and Pages, so the stats can't be recalculated correctly (The events of SAKAI_EVENT are wrong). This is the best I got, at least it shows something rather than 0 - 0%, but the values of the "Pages Read" are not correct, the others are:

If someone else would like to take a look, the changes are in this branch, 0% reliable:

Yeah, I agree, I wouldn't block the release for this. But I would either disable the widget or at least this part of the widget.

Based on what you found on LSNBLDR-736 it seems like there should be /item and /page and there is no support in Sitestats for the /item feature.

From what I can see there still are events for "/lessonbuilder/page" that are generated but perhaps /page/ and /item/ are tracking different things. (It looks like /page/ actually tracks student pages and /item/ tracks everything else)

So maybe we should just switch to /item/ and perhaps have a feature request for a column to track student page reads? (Which would be /page/) ?

My opinion is that LSNBLDR-736 fixed a legitimate bug, where lesson's events were sometimes ambiguous because you can have a page and an item with the same ID. Previous to that fix, the code would always build the event ref with the "/page/" identifier for both SimplePage and SimplePageItem objects, so when resolving the event to an object you would never really know if it's referring to an Item or a Page.

I think the solution to this ticket is to fix the fix the Lessons Widget in Statistics so that it's querying for the proper data.

I've added a PR that resolves the issues with the items and pages, differentiates between page and item. It also adds a new feature that is really useful, the page visited by the user, now it looks much better:

This will require a conversion script to fix the old events and recover the statistics, I've tested this and worked for me:

I'm wondering about that conversion script. You're changing all 'item' refs to 'page' refs, but I don't think you can make this assumption. Given the problem described in LSNBLDR-736, these historical events are ambiguous; they could have been referring to Page or Item objects. I think there's no possible way to determine retroactively if these events actually refer to Page or Item object.

That's amazing Miguel, this is absolutely a blocker IMO and needs to be urgently solved. Sakai lack of this kind of statistics and this is really important for a lot of institutions. Thanks for the effort!

I have not been successful in running the script, since I get a timeout. This is probably because my sakai_event table contains to many rows. I changed the script a bit, but I still won't get it to work. It seems like we have a procedure where we move events from the table into another table from time to time, my guess is because it gets to big. So to solve this issue now for me I will probably have to move data from the table, but that kind of breaks the historic statistics, so I guess we will settle for the future statistics issue.