Provide filter on Revision Dashboard to show new users changes only



Mozilla Developer Network
5 years ago
4 years ago


(Reporter: Trevor, Unassigned)



(Whiteboard: [type:feature])



5 years ago
It would be useful to be able to filter changes made by new users as it would make catching spam users easier and quickly review changes by genuine new users.

Comment 1

5 years ago
Priority: -- → P2
Whiteboard: feature request;
My proposition for the (default) definition of a new user:

A new user is a user with less than 20 edits or (yes "or", not "and") less than 7 days since first login.

Comment 3

5 years ago
Maybe a minor difference, but I would change 7 days since first login to 7 days since first edit.
Oh yes, good idea.

Comment 5

5 years ago
Commits pushed to master at
Fix bug 812728: Rev dash - Add filter for changes from new users
Merge pull request #932 from Elchi3/dash-newusers-812728

Fix bug 812728: Rev dash - Add filter for changes from new users


5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED
This is merged and pushed to production, but the query is very slow, as predicted by :jsocol. (
Reopening as there's currently a stack overflow issue.
Resolution: FIXED → ---

Comment 9

5 years ago
Commits pushed to master at
bug 812728 - waffle new user filter
Merge pull request #934 from groovecoder/waffle-dash-new-user-filter-812728

bug 812728 - waffle new user filter
So, what's slow here? Is it getting the new users with the raw query or the creator_id IN(x,y,z, ...) filter (which contains a large amount of ids probably)?
If the former, can we cache the raw query then or write a task to get the new users every x minutes only?
Or a whole different approach? What would you suggest?
I suspect the issue is with the first query[1] that select ALL the "new users" by looking at ALL revisions ever created.

But with it breaking, it's hard to be sure.

I was wrong - it wasn't slow it was broken.
Hm, would love to see bug 665084 fixed here (a more real, local database to test against to for these kind of features would be so cool!). Will see if I manage to limit the user lookup to not to look into ALL revisions.
The vagrant install instructions include a step to download and import a sanitized production data dump:
Whiteboard: feature request; → [type:feature]
Depends on: 665084
No longer depends on: 665084
Where does this bug stand? Did it ever get fixed?
Not fixed. Unknown level of effort to do the queries.
You need to log in before you can comment on or make changes to this bug.