Bugzilla allows bugs to be assigned to disabled users

RESOLVED WONTFIX

Status

()

Bugzilla
Creating/Changing Bugs
P2
normal
RESOLVED WONTFIX
17 years ago
11 years ago

People

(Reporter: seph, Assigned: Paul)

Tracking

(Depends on: 1 bug)

Details

(Whiteboard: [people:owner] consistency)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17 i686)
BuildID:    cvs20010709

deleting users is generally a bad idea, since old bug reports referance them, so
there's this handy disable user feature. Unfortunatly I can still assign bugs to
a disabled user, which is horrible.

Reproducible: Always
Steps to Reproduce:
1. create user
2. disable user
3. create new bug assigned to disabled user

Actual Results:  the bug was created assigned to the disabled user

Expected Results:  bugzilla shouldn't have allowed the bug to be assigned.

I'm using the debian package of a cvs checkout, so I might have the build ID
wrong. I don't think this is a bug specific to the debian package.
This is a Bugzilla issue, not a browser one.
Assignee: asa → myk
Component: Browser-General → Creating/Changing Bugs
Product: Browser → Bugzilla
QA Contact: doronr → matty
Target Milestone: --- → Bugzilla 2.16
Version: other → unspecified
(Reporter)

Comment 2

17 years ago
the bugzilla helper is horrible and confusing and doesn't seem to have a
bugzilla entry. sorry for mis-catagorizing it.
Confirming (only because we don't use UNCONFIRMED in the Bugzilla product)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Whiteboard: [people:owner] consistency
Dave: one way to fix this would be to check for disabled-ness in DBname_to_id()
in globals.pl. We would then return a relevant error code and
DBNameToIdAndCheck() could print an error.

However, would this prevent people doing legal things with a disabled username?
For example, would it stop people making changes to bugs on which they were CCed
or QA contact until they removed them?

If we don't fix this globally, we need to come up with the list of things you
can't do for a disabled username, and check for all of them explicitly. :-(

Gerv
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

Updated

15 years ago
OS: Linux → All
Hardware: PC → All
I guess the approach here is to get a User object to expose disabledtext, and
then check it in the cases you don't want disabled users used.

What are those cases? Any time that user is put on a bug (assignee, QA, CC)?

Gerv

Updated

14 years ago
Summary: bugzilla allows bugs to assigned to disabled users → Bugzilla allows bugs to be assigned to disabled users
Assignee: myk → brendan
Note: the User object will expose disabledtext when my email table changes get
checked in (bug 73665).

Gerv

Comment 8

14 years ago
(In reply to comment #6)

> What are those cases? Any time that user is put on a bug (assignee, QA, CC)?

My thought is exactly that.  Prevent a disabled user from becoming the 
assignee, QA contact or being added to the CC list.  Also, sanitycheck.cgi 
should warn when any open defect has a disabled user in any of those three 
fields.
Pushing out bugs that aren't blockers.  If someone's working on one of these, we
can move it back.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
*** Bug 252128 has been marked as a duplicate of this bug. ***

Comment 11

14 years ago
note that nobody@mozilla.org is disabled. simply enforcing this will mess bmo up
pretty badly.

Comment 12

13 years ago
*** Bug 148079 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.
Target Milestone: Bugzilla 2.20 → ---
(Assignee)

Comment 14

12 years ago
Created attachment 204296 [details] [diff] [review]
patch to check the user is not disabled according to the parameter of the function match()

$exclude_disabled was not being respected on single user instances.
(Assignee)

Updated

12 years ago
Attachment #204296 - Flags: review?(mkanat)

Updated

12 years ago
Assignee: brendan → pdemarco
Severity: major → normal
QA Contact: mattyt-bugzilla → default-qa
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED

Comment 15

12 years ago
Comment on attachment 204296 [details] [diff] [review]
patch to check the user is not disabled according to the parameter of the function match()

this will break bmo. try again.
Attachment #204296 - Flags: review?(mkanat) → review-
(Assignee)

Comment 16

12 years ago
(In reply to comment #11)
> note that nobody@mozilla.org is disabled. simply enforcing this will mess bmo
> up pretty badly.
 

Because bmo is using a hack to get nobody@mozilla.org to work??   Why can't nobody@mozilla.org get his disabled text removed?

Comment 17

12 years ago
Implementing this will break bugzilla.gnome.org as well.
(Assignee)

Updated

12 years ago
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.24
(Assignee)

Updated

12 years ago
Depends on: 98310

Comment 18

12 years ago
As stated in various comments, I think this is something we're not going to fix. "Disabled" means "can't log in." We should probably just make that clearer by making the checkbox say "disable login" or something like that.

Perhaps we could have another checkbox for "this user cannot be added to any new bugs." That does seem to start to get complex, though.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX

Updated

12 years ago
Target Milestone: Bugzilla 2.24 → ---

Updated

11 years ago
Duplicate of this bug: 388938
You need to log in before you can comment on or make changes to this bug.