Deleting a user account may delete other user's whine

RESOLVED FIXED in Bugzilla 3.0

Status

()

Bugzilla
User Accounts
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: Wurblzap, Assigned: Frédéric Buclin)

Tracking

({regression})

3.0.1
Bugzilla 3.0
regression
Bug Flags:
approval +
blocking3.1.3 +
approval3.0 +
blocking3.0.3 +

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
This is a regression of bug 119485.

When deleting a user account, all whines (other users', too) where the account being deleted is a direct whinee of will be deleted along with the user account. Instead of deleting the whine as a whole, it should delete the schedule only.

Steps to reproduce:
1. Create a user A (which is the one to be deleted later)
2. Log in as user B
3. Create a whine; create schedules to it so that user A and user B are
   both whinees
4. Delete user A

This deletes the whine created in step 3.
(Reporter)

Updated

10 years ago
Keywords: regression
(Assignee)

Updated

10 years ago
Target Milestone: --- → Bugzilla 3.0

Comment 1

10 years ago
This should actually be handled automatically by referential integrity in 3.1. You could try just deleting the profiles entry and a few other things, and see if that actually works. (It should, because of DELETE => 'CASCADE' on most items.)
(Assignee)

Comment 2

10 years ago
I would hate to see one of my whines being deleted because only one addressee no longer exists. Pushing this regression into our radar for 3.0.3/3.1.3.
Flags: blocking3.1.3+
Flags: blocking3.0.3+
(Assignee)

Comment 3

10 years ago
Created attachment 289298 [details] [diff] [review]
patch, v1
Assignee: user-accounts → LpSolit
Status: NEW → ASSIGNED
Attachment #289298 - Flags: review?(wurblzap)
(Reporter)

Comment 4

10 years ago
Comment on attachment 289298 [details] [diff] [review]
patch, v1

r=Wurblzap by inspection and believing that I know the code well enough.
Attachment #289298 - Flags: review?(wurblzap) → review+
(Assignee)

Updated

10 years ago
Flags: approval3.0+
Flags: approval+
(Assignee)

Comment 5

10 years ago
tip:

Checking in editusers.cgi;
/cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v  <--  editusers.cgi
new revision: 1.145; previous revision: 1.144
done
Checking in template/en/default/admin/users/confirm-delete.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/users/confirm-delete.html.tmpl,v  <--  confirm-delete.html.tmpl
new revision: 1.20; previous revision: 1.19
done


3.0.2:

Checking in editusers.cgi;
/cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v  <--  editusers.cgi
new revision: 1.141.2.1; previous revision: 1.141
done
Checking in template/en/default/admin/users/confirm-delete.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/users/confirm-delete.html.tmpl,v  <--  confirm-delete.html.tmpl
new revision: 1.15.2.2; previous revision: 1.15.2.1
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Keywords: relnote

Comment 6

9 years ago
Probably already relnoted in 3.0.3--in any case, it doesn't need to be relnoted for 3.2, so removing relnote keyword.
Keywords: relnote

Comment 7

9 years ago
Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.
(Assignee)

Comment 8

9 years ago
(In reply to comment #7)
> Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.

You just said the opposite in comment 6?!

Comment 9

9 years ago
(In reply to comment #8)
> You just said the opposite in comment 6?!

  Oh, mistake. I did that with a "Change Several Bugs At Once", so I probably accidentally checked this bug.

Comment 10

9 years ago
is there anyway that we can just disable the users account on temporary base.
and i don;t want some of the email id to be seen in some of the projects.

i need one project assigned to one person and other persion email id should not be seen in unassigned project. Is that possible ? if so please do let me know as soon as possible as it is my requirementst with the clients.
You need to log in before you can comment on or make changes to this bug.