[Koha-bugs] [Bug 12235] New: Logs organized inconsistently

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12235

            Bug ID: 12235
           Summary: Logs organized inconsistently
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Transaction logs
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: dcook at prosentient.com.au
        QA Contact: testopia at bugs.koha-community.org

The database structure for the transaction logs doesn't work very well.

When you view the "Modification log" for a patron or a bib record, you're
viewing the logs for the "object" with that borrowernumber or biblionumber.

However, this often has surprising results, especially in the "Catalog" module.

For instance, the "Modification log" for bib record #1 will show you the logs
for bib record #1...and item record #1. However, if won't show you the logs for
item record #2, which is attached to bib record #1.

This is a problem.

While it might be fair that the "Modification log" for bib record #1 shouldn't
have to show the logs for its attached items, it shouldn't show unrelated
results for other items.

--

A structure more in line with expectation might be something like:

-System user (i.e. the librarian)
-Biblionumber
-Itemnumber (or maybe AttachedNumber so this could be either items or serials)
-Info

Or at least some other way of differentiating what is in the "object" column. 

I had to perform 3 different (arguably "expert") queries just to find out that
item #2 from bib record #1 was checked in by patron #3.

Why?

First query: Retrieve bib record...don't find correct item information using
bib ionumber object
Second query: Retrieve item record using correct itemnumber object...
Third query: Search for itemnumber in "info" column, so that it brings up the
circulation transaction.

--

I'm tempted to write a patch for this, but I wonder about pre-existing logs. Do
we try to convert them to match a new schema, or do we ignore them, or do we
back them up then wipe the table for fresh logs?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.