Should we remove ability to turn on user and bug deletion?
Benton, Kevin
kevin.benton at amd.com
Mon Apr 4 19:18:58 UTC 2005
> -----Original Message-----
> From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]
> On Behalf Of Marc Schumann
> Sent: Monday, April 04, 2005 11:05 AM
> To: developers at bugzilla.org
> Subject: Re: Should we remove ability to turn on user and bug
deletion?
>
> On Apr 4, 2005 10:54 AM, Gervase Markham <gerv at mozilla.org> wrote:
> > The newsgroups are filled with people who have turned on user and
bug
> > deletion, despite the warnings, and got into difficulty. I say we
should
> > remove the Params, and tell people it's not supported, until such
time
> > as someone implements it properly.
> >
> > What do you think?
>
> User deletion has improved a lot with bug 119485. On user deletion,
> the admin is presented with individual, detailed warnings. Short of
> deleting bugs, related entities are deleted along with the user.
> Leaving the bugs undeleted will cause db inconsistency when overriding
> the corresponding warning. Maybe it's an idea to go for the
> never-inconsistencies way, but I don't think this warrants to make
> user deletion impossible.
As a Bugzilla Administrator, it seems like a lot of work at this point
to perform deletions of users if that user has had much activity in the
system at all. If the user is an assigned-to person, has commented on
bugs, has created activity log entries, attachments, etc., there's a lot
to deleting that user without creating referential problems. On the
other hand, if we have a "deleted" flag, it would be relatively easy to
handle clean-up because the user should no longer have access to the web
or email interfaces, and there's no need to handle activity log entries
in a special manner because they're still stored in the database. In
the event a system admin decides they made a mistake, no data has been
lost, they can simply turn the user back on. In my mind, a user flagged
as deleted would no longer show up in user lists, hyperlinks to them
would be disabled, and the only way to gain access to those users would
be to request to include a listing of deleted users from the user
administration menu, and of course, from MySQL directly.
As a Bugzilla programmer, it makes a lot of sense to me to give the
ability to "permanently and completely disable a user" without having to
remove them from the DB. I believe it would be extremely rare when
administrators would actually want to physically remove "old users" from
the system short of running out of disk space or the user table gets
"too big." In those cases, I think we need to come up with a way to set
up a default user that all entries can be reassigned to in the event
that a user deletion is required. If not a default user, then I feel we
should give the person performing the deletion the opportunity to pick a
person or assign the bugs back to the person doing the deletion. In
those cases, a set of updates could be written to update all the user id
foreign keys changing any instance of the user being deleted to the
appropriate user id. By doing this, we haven't thrown out any
historical information, and we can now completely remove the user from
the system without breaking any references. It also makes querying the
database relatively easy, giving the administrator immediate access to
any bugs that need to be reassigned after the user has been removed.
Another benefit of this auto-reassignment method is that it makes it
easier to back-out any changes made by a real user deletion. All the
changes made to bugs and other foreign keys containing that user's id
can be reverted because the listing of those changes should be available
in a query.
---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information. Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices. This
communication is for the intended recipient(s) only. If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.
More information about the developers
mailing list