142736 - Administrative operations should be logged in the database

Status: RESOLVED DUPLICATE of bug 622943

(Bugzilla :: Administration, task, P2)

Description

[Jouni Heikniemi]

Certain administrative operations should be logged in a text file, as the
database doesn't have fields to store information about the
creator/editor/lastmodified of
products/components/groups/attachmentstatuses/keywords and so on. I don't think
it's worth the effort to add this sort of data into the db. 

I have been working on this kind of functionality on our own BZ installation and
can refine the patch for the Bugzilla CVS if the team decides that this feature
is wanted. I will post more exact specs of my plans later. 

Ccing Gerv per discussion on n.p.m.webtools.

Comment 1

[Gervase Markham [:gerv]]

First, you will have to put up a case for why we need this. Can't you trust your
admins? :-)

Then, you will have to put up a very good case for why this information should
not be stored in the DB. Every time (duplicates, charts) we've stored
information outside the DB for something, we've regretted it later, had to move
it inside, and had migration headaches.

We already have a bug_activity table - we could easily have an admin_log table
with a userid, an operation, and some parameter data about exactly what they did
- or something like that.

Gerv

Comment 2

[Jouni Heikniemi]

>First, you will have to put up a case for why we need this. Can't you trust your
>admins? :-)

It's not a question of trust, but if we want to view it that way: No, I don't
trust that all the admin accounts necessarily stay in their rightful owner's
hands forever. Plaintext passwords and unlocked workstations are a risk, and
humans tend to err. 

The true reason is that I don't feel comfortable with a system that allows such
drastic changes to be made without even some sort of traces left. That creates
quite a big hole in the net of software our servers run. Most of them write some
sort of logs which can be automatically monitored. Bugzilla unfortunately isn't
part of this group right now. I feel it's simply good software design to give
the  Administrator a log file which reflects changes critical to the system.

>Then, you will have to put up a very good case for why this information should
>not be stored in the DB. Every time (duplicates, charts) we've stored
>information outside the DB for something, we've regretted it later, had to move
>it inside, and had migration headaches.

I'm not absolutely adamant on this, so I could be persuaded for the DB approach
as well ;-) But there are some good arguments for the text file:

- text files are de facto standard for logging, and there are kazillion tools
  available for handling, rotation, monitoring and so on. 
- text files can be easily browsed without a special interface
- text files don't bloat the database (although I don't think the impact would
  be significant anyway)
- writing text files is slicker and more efficient (not a tremendous issue
  either)

On the other hand, database could be cool because:

1. all the data would stay in one place
2. the log could be browsed easier through the web
3. the log would be backed up with other data

As for 1 and 3, I think they're good points but also feasible the other way
around: it's good to have all the system logs in one place. Number 2 is a more
significant point if the web browsing interface should be implemented, but that
sounds like unnecessary payload. The administrator probably has shell access
anyway, so he can certainly check the log that way too.

>We already have a bug_activity table - we could easily have an admin_log table
>with a userid, an operation, and some parameter data about exactly what they did
>- or something like that.

Yes, that would be a good approach, too. But after considering all this over
again, I'm still slightly tilted towards the text file implementation. What say you?

Comment 3

[Andreas Franke (gone)]

Maybe in the long run, it would be best to add a highly configurable option to
let bugzilla write a log file, independent of whether or not the product
creation operations (and possibly others) are stored in the database.
With such a configurable logging mechanism, the admin could set the log level
once upon installation, and change it (or enable/disable logging in specific
areas) when the need arises. I recently discovered the existing data/sqllog
mechanism which is turned on as soon as that file exists and is writable.
Then there are the web server access and error logs, but they are probably not
particularly well suited to reconstruct the creator of a product...

Comment 4

[Matthew Tuck [:CodeMachine]]

There is already a table called profiles_activity that was intended to be
something along these lines.

Comment 5

[Gervase Markham [:gerv]]

Are we not using it, then?

Also, from the name, it rather implies that it doesn't log the sort of
enhancements that Jouni is concerned about.

Gerv

Comment 6

[Jouni Heikniemi]

profiles_activity has the same idea, but covers only a very narrow slice of all
the administrative operations. 

I've been further refining my plans on this, hope I'll have time to write them
down soon. I'll post some suggestions to this bug then. 

Comment 7

[Matthew Tuck [:CodeMachine]]

I'm not sure if we're using it.

And yes I know it implies it doesn't log everything, that was just an example to
show we had something.

Comment 8

[Jouni Heikniemi]

Dave, do you think this kind of feature would be useful in Bugzilla (meaning
"would I ever get an approval on this")? I still have some of this functionality
on our installation, but most of it would need a rather heavy rewrite to be
sufficiently customizable for Bugzilla.

Even if you say yes, I still don't have much time for this, but in the case of a
no, I would like to get this off my list.

Comment 9

[Dave Miller [:justdave]]

I think this is a needed feature.  I'd rather it write to the database than an
external file (we need a UI for profiles_activity - and we probably ought to
have activity tables for other admin functions as well)

Comment 10

[Jouni Heikniemi]

Ok. Since we aim for the DB support, this clearly exceeds whatever time I can
allocate in the near future. Reassigning to [e-mail]. 

Comment 11

[Dave Miller [:justdave]]

-> [e-mail]

Comment 12

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 13

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

Comment 14

[Frédéric Buclin]

See also bug 100090. Closely related but this one could be implemented independently of bug 100090.

Comment 15

[Frédéric Buclin]

Serge, any reason you reset the priority of this bug?

Comment 16

[Serge Gautherie (:sgautherie)]

(In reply to comment #15)

Probably a mistake: I may have looked at the P4 from 2002 :-(
Restoring P2.