Summary: | Renewals do not add branchcode to statistics table | ||
---|---|---|---|
Product: | Koha | Reporter: | Ian Walls <koha.sekjal> |
Component: | Circulation | Assignee: | Chris Cormack <chris> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | enhancement | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, gmcharlt, jwagner, nengard |
Version: | 3.6 | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: |
Proposed Patch
Follow up patch |
Description
Ian Walls
2010-09-03 16:09:42 UTC
This problem has plagued us (and our statistics preparation) for a long time. I don't know how SCO determines the user's branch--does it credit the patron's home branch with the circulation rather than the location at which the checkout is being made? My preference for crediting the branch for online renewals would be to give the circ statistic to the branch which originated the checkout rather than to the patron's home branch. In my multi-library system the patron's home branch doesn't necessarily have much to do with the libraries they actually use. I haven't tested this - but does your SCO staff user have a branch associated with them? I would think this is the branch that should be credited - just like when the staff log in their branch is credited with the check outs. This of course means you need a SCO user for each branch (which is also a good idea). For SCO, the homebranch of the SCO staff account should be used, since that can be customized by the library on a per-SCO-terminal basis. For opac renewals, there seem to be a few options: -Credit the library that originated the circ -Credit the patron's home branch -Credit the library that owns the item -Use CircControlBranch to determine which of the above three to use -Create a new system preference just like CircControlBranch, but for OPAC renewal Other options include: -Use a code like "OPAC" (would break if there were an 'OPAC' branchcode) -Define a new statistic type "Self Renewal" -Leave it as null Thoughts? > -Use a code like "OPAC" (would break if there were an 'OPAC' branchcode) This creates difficulties if you're designing reports around your branch codes, i.e. creating a table of circ stats with one branch in each column. > -Define a new statistic type "Self Renewal" I don't think this helps the situation. We're still left with wanting to be able to aggregate circulation stats for each branch. At best this makes explicit what is now only implied by a null value. My vote is definitely to credit the library which originated the checkout. I'm with crediting the library that initiated the checkout - since that's how it's done at the circ desk. What I'm wondering is is there any other way to know that it was done at the self checkout terminal? Can that be done by querying against the self checkout user that is logged into the terminal? If not then there should be a way to get numbers of how many people used the self checkout versus how many items were checked out from the circ desk. Just want to give this bug a little bump, since it's effecting statistics reports for librarians. This was discussed today on irc and on the mailing list. I think for opac renewals the best option is a sys pref where the behaviour can be chosen. Will work on a patch I think I have it working now, changing the system preference means it records the appropriate branch select * from statistics; +---------------------+-----------+----------+--------+-------+-------+----------+------------+----------+----------------+--------------------+ | datetime | branch | proccode | value | type | other | usercode | itemnumber | itemtype | borrowernumber | associatedborrower | +---------------------+-----------+----------+--------+-------+-------+----------+------------+----------+----------------+--------------------+ | 2011-05-06 11:12:59 | CPL | NULL | 5.0000 | issue | | NULL | 1 | BK | 51 | NULL | | 2011-05-06 11:14:47 | CPL | NULL | 5.0000 | renew | | NULL | 1 | BK | 51 | NULL | | 2011-05-06 11:15:48 | OPACRenew | NULL | 5.0000 | renew | | NULL | 1 | BK | 51 | NULL | +---------------------+-----------+----------+--------+-------+-------+----------+------------+----------+----------------+--------------------+ Patch to follow The patch does not change the self checkout part, only OPAC renewals. Created attachment 4045 [details] [review] Proposed Patch Chris, this works beautifully unless you choose NULL after having it set to another value. I had it set to OPACRenew and then I set it to items branch and they both worked then I set it to NULL and it put OPACRenew in the table. We might need someone else to test to confirm my results. I see the problem, follow up patch sent Created attachment 4052 [details] [review] Follow up patch Verified that "OpacRenew" option should work, even if it's not a valid branchcode in the system. Patch covers all languages syspref files, updatedatabase, preference editor, and code itself. Followup corrects comparison error. Marking as Passed QA Pushed to master, please test While this patch fixes the issue going forward, it does not repair lost statistics for systems that ran with the bug in effect. A separate cleanup script should be written so folks can restore their OPAC renewal stats, based on the current system preference's setting. This appears to be working. Closing. |