The Individual info is off. and because it has a zero for the current week the project doesn't show up on the main statistics page.

http://drupal.org/project/usage/user_register_notify

Comments

dww’s picture

Title: Ussage statistics not being generate right for at least 1 project. » Weekly usage stats not processed if we have a full week of data but we processed less than 1 week ago
Version: x.y.z » 5.x-1.x-dev
Assigned: Unassigned » dww
Status: Active » Needs review
StatusFileSize
new2.24 KB

The bug here is that on d.o right now, due to having to manually trigger weekly processing in the wake of #326197: Empty data for latest week, the weekly processing is out of sync with when new weeks actually start. This untested patch tries to cover this case by processing if we've got more than a full week of unprocessed data, even if we've processed some data less than a week ago. It preserves the logic where if we skip processing for a week or more, we still don't skip weeks the next time we do process and catch up on any weeks since we last processed. I think the code comment is pretty clear, but this needs review (preferably from drewish) and testing before I deploy it.

A related problem is that the table of stats for releases by core API version at the bottom of per-project usage stat pages (like you pointed to) doesn't ensure there's data for the listed weeks -- it just creates rows in that table based on the calendar, not what data we have in the DB. We should also fix that, but that part isn't included in this patch.

"and because it has a zero for the current week the project doesn't show up on the main statistics page."

Nope, not true at all. ;) Look at http://drupal.org/project/usage and search for "User registration notification" -- it's there (right between "Messaging" and "Admin Role").

drewish’s picture

StatusFileSize
new2.21 KB

I think this can be simpler. Looking at your patch I had to puzzle over what project_usage_weekly_timestamp() was doing and in the process realized that it's parameters weren't documented well so I spun those fixes off to #345913: Make day/week offset arguments consistent and properly documented.

If you look at the original logic it was basically trying to say we can't run the weekly if it hasn't been a full week... which would work perfectly if the first run was at 1am GMT on Monday morning. The problem is that it's using now - a week rather than rounding now to the beginning of this week. Which I realized after playing with the tests is exactly what project_usage_weekly_timestamp() does.

As a bonus I'm adding in a variable that was missing from the hook_uninstall.

drewish’s picture

I've forked #346046: Weekly API and release tables shouldn't show list unprocessed weeks to deal with the display of the missing rows in the tables.

dww’s picture

Status: Needs review » Fixed

I finally had a chance to re-sync the DB tables and test this on p.d.o. It's all working as expected, so I committed to HEAD + DRUPAL-5, and deployed on d.o.

I'm backing up the d.o tables now, and once that's done, I'll run the processing script manually to generate the Dec 7th data.

dww’s picture

FYI: d.o's usage DB tables saved, ran the processing script manually, and everything worked as expected. It did not try to re-process the daily data (which already happened ~8 hours ago), but it did process the weekly data. Everything looks great now: http://drupal.org/project/usage/drupal

So, we're just down to the race condition that #346046: Weekly API and release tables shouldn't show list unprocessed weeks will close and we should be golden.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.