Summary: | Add reserves to modification logging | ||
---|---|---|---|
Product: | Koha | Reporter: | Liz Rea <wizzyrea> |
Component: | Staff interface | Assignee: | MJ Ray (software.coop) <mjr> |
Status: | RESOLVED DUPLICATE | QA Contact: | Bugs List <koha-bugs> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | gitbot, gmcharlt, jonathan.druart, kyle, marjorie.barry-vila, mjr, tomascohen, veron, wizzyrea |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | Sponsored | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: |
C4/Reserves.pm: log reservation actions catalogue/issuehistory.tt: link to viewlog for circulation log tools/viewlog.tt: add HOLD and UNHOLD actions, move results table nearer top tools/viewlog.pl: be more cautious in assuming info field in CIRCULATION is
Bug 6890 - log reservation actions Bug 6890 - log reservation actions |
Description
Liz Rea
2011-09-20 21:09:44 UTC
It would be nice to be able to see that a logged in user (or if the patron) placed or filled a reserve, wouldn't it? At first glance this can't be done in master but I think I can see how to do it (key bit is to add UpdateStats calls to C4::Reserves). Created attachment 8945 [details] [review] C4/Reserves.pm: log reservation actions catalogue/issuehistory.tt: link to viewlog for circulation log tools/viewlog.tt: add HOLD and UNHOLD actions, move results table nearer top tools/viewlog.pl: be more cautious in assuming info field in CIRCULATION is There are many ways that this could be done: C4::Log, C4::Stats and the issues table to name but there. Here is my implementation using C4::Log. CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/tools/viewlog.tt :( I was looking forward to this too. Created attachment 14109 [details] [review] Bug 6890 - log reservation actions C4/Reserves.pm: log reservation actions catalogue/issuehistory.tt: link to viewlog for circulation log tools/viewlog.tt: add HOLD and UNHOLD actions, move results table nearer top tools/viewlog.tt: rewrite to use loopro.module and to link better members/readingrec.tt: link to circulation log for hold/unhold info To test: 1. place a few holds and release them somehow (cancel or issue); 2. view the reading record of an affected borrower; 3. click the link to the modification log and see the holds; 4. click the link to an affected biblio; 5. click to view its circulation history; 6. click the link to the modification log and see the holds. It blooming well did after I rebased on 2012-12-14 :-( Created attachment 21817 [details] [review] Bug 6890 - log reservation actions C4/Reserves.pm: log reservation actions catalogue/issuehistory.tt: link to viewlog for circulation log tools/viewlog.tt: add HOLD and UNHOLD actions, move results table nearer top tools/viewlog.tt: rewrite to use loopro.module and to link better members/readingrec.tt: link to circulation log for hold/unhold info To test: 1. place a few holds and release them somehow (cancel or issue); 2. view the reading record of an affected borrower; 3. click the link to the modification log and see the holds; 4. click the link to an affected biblio; 5. click to view its circulation history; 6. click the link to the modification log and see the holds. Patch applied cleanly, go forth and signoff The logs should be written only if a pref is set. It is the usual way to log actions into Koha. Marked as Failed QA. In reply to comment 9: > The logs should be written only if a pref is set. > It is the usual way to log actions into Koha. What pref should be set? What coding guideline sets this out? (In reply to MJ Ray (software.coop) from comment #10) > In reply to comment 9: > > The logs should be written only if a pref is set. > > It is the usual way to log actions into Koha. > > What pref should be set? > > What coding guideline sets this out? Hello MJ, You can have a look at admin/preferences.pl?tab=logs and at the result of the following command: git grep logaction The action_logs table is filled depending on syspref values, so I suppose you should do the same. If you disagree, you can ask another QAer to have a look. *** This bug has been marked as a duplicate of bug 14642 *** |