Closed
Bug 211164
Opened 21 years ago
Closed 20 years ago
The Series code in collectstats.pl should count secure bugs
Categories
(Bugzilla :: Reporting/Charting, defect, P1)
Bugzilla
Reporting/Charting
Tracking
()
RESOLVED
DUPLICATE
of bug 210735
People
(Reporter: jussi, Assigned: gerv)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030630 Build Identifier: I'm running collectstats.pl once a day and I only get zeroes inserted to the series_data table. The script returns bunch of [Tue Jul 1 02:03:50 2003] collectstats.pl: Use of uninitialized value in pattern match (m//) at Bugzilla/Util.pm line 49. warnings. From the series_data table after running collectstats: | 1 | 2003-06-30 00:00:00 | 9 | | 2 | 2003-06-30 00:00:00 | 1 | | 3 | 2003-06-30 00:00:00 | 0 | | 4 | 2003-06-30 00:00:00 | 0 | | 5 | 2003-06-30 00:00:00 | 9 | ... | 5 | 2003-07-01 00:00:00 | 0 | | 4 | 2003-07-01 00:00:00 | 0 | | 3 | 2003-07-01 00:00:00 | 0 | | 2 | 2003-07-01 00:00:00 | 0 | | 1 | 2003-07-01 00:00:00 | 0 | ... The queries for the data sets in the New Charts page return valid bug counts. I can reproduce this by deleting the last days entries from series_data and by rerunning collectstats.pl. I have custom datasets defined but I could not reproduce this on a clean install. (But could with the db from another host) Reproducible: Always Steps to Reproduce:
Reporter | ||
Comment 1•21 years ago
|
||
Did the collectstats.pl do some group checking? Most of the bugs belong to some group because of pre-requirelogin days.
Reporter | ||
Comment 2•21 years ago
|
||
Yes, if the bug is in a group, then it is not counted. Steps to reproduce: 1. Create new bz installation. 2. Insert a bug. 3. Create a new group and insert the bug into the group. 4. Run collectstats.pl --> All counts are zero.
Reporter | ||
Comment 3•21 years ago
|
||
This goes a bit over my knowledge of Bugzilla, but I would guess that the Bugzilla::Search module needs Bugzilla->user to be initialized and the new authentication mechanism allows this to be done only by calling Bugzilla->login.
Reporter | ||
Comment 4•21 years ago
|
||
Bradley Baetz has described the behaviour already in bug 210735, comment 4. Should read my bugmail before looking elsewhere. Sorry for the spam.
Reporter | ||
Comment 5•21 years ago
|
||
Since I wanted to collect data for different seriesses, I tried to fix this by making Bugzilla->user a setter. This was not enough because it seemed that $serieses->{$series_id}->{'creator'} was undefined in CollectSeriesData (bug 210735). For the time being I setled for making Bugzilla->user a setter and by giving a known userid to the Bugzilla::User constructor.
Depends on: 210735
Assignee | ||
Comment 6•21 years ago
|
||
This should be fixed by the patch to bug 210735 - each query will then run with the permissions of its creator. Gerv
Reporter | ||
Comment 7•21 years ago
|
||
I was under the impression that doing $::vars->{'user'} = Bugzilla->user(new Bugzilla::User($serieses->{$series_id}->{'creator'}) is not enought to 'log in' the creator (bug 210735, comment 4).
Assignee | ||
Comment 8•21 years ago
|
||
Fair point... Gerv
Assignee | ||
Comment 9•21 years ago
|
||
Right. To fix this we need to: - Make Bugzilla->user a setter - Set it to new Bugzilla::User($creator) in collectstats.pl. Then each query will run with the permissions of its creator. In the mean time, collected values will contain public bugs only. We should document this as a restriction (see bug 224420).
Assignee | ||
Updated•21 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Bugzilla 2.18
Assignee | ||
Updated•21 years ago
|
Priority: -- → P1
Assignee | ||
Updated•21 years ago
|
Summary: Zero values inserted to series_data table by collectstats.pl → The Series code in collectstats.pl should count secure bugs
Comment 10•20 years ago
|
||
All 2.18 bugs that haven't been touched in over 60 days and aren't flagged as blockers are getting pushed out to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Assignee | ||
Comment 11•20 years ago
|
||
This was fixed by the patch in bug 210735 - at least, my local installation now counts secure bugs correctly, as far as I can tell. Gerv *** This bug has been marked as a duplicate of 210735 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Target Milestone: Bugzilla 2.20 → ---
Comment 12•19 years ago
|
||
*** Bug 274043 has been marked as a duplicate of this bug. ***
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•