Description
Katrin Fischer
2013-05-27 13:10:20 UTC
I'd like to add to this that this is also patrons, not simply items and bibs. I think each one of these should be assigned a unique number, i.e. no item number should be assigned a number that already exists as a bib number or a patron number. I realize we can't fix existing records, but we can certainly ensure this doesn't happen going forward. Created attachment 89668 [details] [review] Bug 10352: Display the correct modification logs for bibliographic records The 'Modification log" link in the cataloguing module returns confusing results. The 'object' parameter is the biblionumber, but the all log from itemnumber=biblionumber will be displayed as well. Since bug 11473 we have the action_logs.info column that is prefixed by 'item ' or 'biblio ' to disociated an item modification from a biblio modif. This patch suggests a quick and dirty approach, use this column to make sure we are searching for the correct logs. /!\ As bug 11473 did not update the existing rows, we will no longer display the logs created prior to this change. Test plan: Make sure you have at least 2 bibliographic records with some items Make sure you have the biblionumbers of those records that match existing itemnumbers Edit them (no matter what you change) Go to the bibliographic detail page (staff) and click "Modification log" You should see the correct changes. Jonathan, would it be better to have an "old logs" mode, where things work the old way? People might need to access old logs after an upgrade and we'd be taking those away from them (unless I am misunderstandng what you've said here). Liz I was talking about "prior to bug 11473", so 3.16.x. No access old logs vs access the wrong logs? :) There are libraries outu there with history that long, though I"m not sure they'd ever have a reason to go back that far. It's probably fine. (In reply to Liz Rea from comment #5) > There are libraries outu there with history that long, though I"m not sure > they'd ever have a reason to go back that far. > > It's probably fine. The data will still be in the database, right? So I suppose worst case scenario they could do a SQL report? Although that's presuming they'd know that there has been a change to how the log viewer works... *** Bug 10680 has been marked as a duplicate of this bug. *** *** Bug 14444 has been marked as a duplicate of this bug. *** Created attachment 91466 [details] [review] Bug 10352: Display the correct modification logs for bibliographic records The 'Modification log" link in the cataloguing module returns confusing results. The 'object' parameter is the biblionumber, but the all log from itemnumber=biblionumber will be displayed as well. Since bug 11473 we have the action_logs.info column that is prefixed by 'item ' or 'biblio ' to disociated an item modification from a biblio modif. This patch suggests a quick and dirty approach, use this column to make sure we are searching for the correct logs. /!\ As bug 11473 did not update the existing rows, we will no longer display the logs created prior to this change. Test plan: Make sure you have at least 2 bibliographic records with some items Make sure you have the biblionumbers of those records that match existing itemnumbers Edit them (no matter what you change) Go to the bibliographic detail page (staff) and click "Modification log" You should see the correct changes. Signed-off-by: hc <hc@interleaf.ie> This does what is advertised, however, I can no longer view the Cataloging log for items now? I can see them if I click all, but not if I only want cataloging changes for items (In reply to Nick Clemens from comment #10) > This does what is advertised, however, I can no longer view the Cataloging > log for items now? I can see them if I click all, but not if I only want > cataloging changes for items I do not understand what you mean. - Edit an item - Go to the detail page of the bib record - Click "Modification log" - I see the change for the item at the bottom of the page (In reply to Jonathan Druart from comment #11) > (In reply to Nick Clemens from comment #10) > I do not understand what you mean. Sorry, what I meant is that you cannot directly search the catalog logs for an itemnumber - you must now enter the biblionumber - Have an itemnumber that is a biblionumber and one that isn't - Browse to Tools -> Log viewer - Enter the itemnumber in the 'Object' field, select 'Catalog' module - Submit - If the itemnumber is a biblio you get the mod log for the biblio (which may not contain your item) - If the itemnumber is not a biblio you get 'No log found...' We fix the links, but not general searching. Possibly a radio button to choose item/biblionumber if searching catalog? I don't really like that there is magic happening for a cataloging log search Created attachment 95776 [details] [review] Bug 10352: Use a new object_type parameter instead of the module's name To dissociate a search on biblio and item, we pass a new "object_type" parameter to viewlog.pl. If equals 'biblio' we will assume that "object" contains a biblionumber (In reply to Nick Clemens from comment #12) > (In reply to Jonathan Druart from comment #11) > > (In reply to Nick Clemens from comment #10) > > I do not understand what you mean. > > > Sorry, what I meant is that you cannot directly search the catalog logs for > an itemnumber - you must now enter the biblionumber > > - Have an itemnumber that is a biblionumber and one that isn't > - Browse to Tools -> Log viewer > - Enter the itemnumber in the 'Object' field, select 'Catalog' module > - Submit > - If the itemnumber is a biblio you get the mod log for the biblio (which > may not contain your item) > - If the itemnumber is not a biblio you get 'No log found...' > > We fix the links, but not general searching. Possibly a radio button to > choose item/biblionumber if searching catalog? I don't really like that > there is magic happening for a cataloging log search Thanks for the suggestion but I would prefer to avoid adding a new box on the form and play with JS code. I picked the lazy approach, but will fix your concern. Created attachment 95783 [details] [review] Bug 10352: Display the correct modification logs for bibliographic records The 'Modification log" link in the cataloguing module returns confusing results. The 'object' parameter is the biblionumber, but the all log from itemnumber=biblionumber will be displayed as well. Since bug 11473 we have the action_logs.info column that is prefixed by 'item ' or 'biblio ' to disociated an item modification from a biblio modif. This patch suggests a quick and dirty approach, use this column to make sure we are searching for the correct logs. /!\ As bug 11473 did not update the existing rows, we will no longer display the logs created prior to this change. Test plan: Make sure you have at least 2 bibliographic records with some items Make sure you have the biblionumbers of those records that match existing itemnumbers Edit them (no matter what you change) Go to the bibliographic detail page (staff) and click "Modification log" You should see the correct changes. Signed-off-by: hc <hc@interleaf.ie> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Created attachment 95784 [details] [review] Bug 10352: Use a new object_type parameter instead of the module's name To dissociate a search on biblio and item, we pass a new "object_type" parameter to viewlog.pl. If equals 'biblio' we will assume that "object" contains a biblionumber Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Created attachment 95785 [details] [review] Bug 10352: (follow-up) show the biblionumber for items in modification logs This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious To test: 1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber i.e. In the sample data: biblionumber 59 with item with itemnumber 127 item with itemnumber 59 on biblionumber 23 2 - Edit both items however you wish 3 - On biblionumber 59 click the modification log 4 - You should see "Item 127" 5 - Click "Submit" on the form - this searches as itemnumber 6 - You should see "Item 59" 7 - Apply patch 8 - On biblionumber 59 click the modification log 9 - You should see "Item 127 from Biblio 59" 10 - Click "Submit" on the form - this searches as itemnumber 11 - You should see "Item 59 from Biblio 23" Created attachment 95786 [details] [review] Bug 10352: (follow-up) show the biblionumber for items in modification logs This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious To test: 1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber i.e. In the sample data: biblionumber 59 with item with itemnumber 127 item with itemnumber 59 on biblionumber 23 2 - Edit both items however you wish 3 - On biblionumber 59 click the modification log 4 - You should see "Item 127" 5 - Click "Submit" on the form - this searches as itemnumber 6 - You should see "Item 59" 7 - Apply patch 8 - On biblionumber 59 click the modification log 9 - You should see "Item 127 from Biblio 59" 10 - Click "Submit" on the form - this searches as itemnumber 11 - You should see "Item 59 from Biblio 23" Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> I have gone through the test plan, and I would like to understand step 10 a bit more. From the user's perspective, go to the modification log from one bib (bib 59) and see you are getting bib# x and Item #y, but then hitting Submit (never leaving the log page) will retrieve results will get a different "object". No other parameters changed in the system log filter such as Module, Object, Action. How would the user understand the difference? There is a lot of logic that is happening behind the scenes that the user doesn't know. I agree with you Kelly. I would suggest to move forward with those patches, to fix the long standing issue, then deal with an ergonomic improvement on a separate bug report. Missing this one now: 12/06/2019 10:54 Marcel Dev (51) Catalog Add Biblio 474 biblio intranet Getting only item changes. I am not sure if I really understand "deal with ergonomic somewhere else" argument. What we do now, is: Toggle item / biblio. While we want both. I think we should adjust the query on this report. Does not seem to be a large change. (In reply to Marcel de Rooy from comment #21) > I think we should adjust the query on this report. Does not seem to be a > large change. If you are volunteering I am all good with doing it here :) (In reply to Jonathan Druart from comment #22) > (In reply to Marcel de Rooy from comment #21) > > I think we should adjust the query on this report. Does not seem to be a > > large change. > > If you are volunteering I am all good with doing it here :) QA / conflict of interests ;) Created attachment 96273 [details] [review] Bug 10352: Get add operations too When an add for biblio or item is recorded there is no space in the info field This does alleviate the specific missing line that Marcel highlighted, it did point out to me though that item deletions are not going to be picked up here - we need Koha::Old::Items to get the deleted numbers to check the logs. I think this one has pointed out we have more work to do, but doe offer improvement Created attachment 96336 [details] [review] Bug 10352: Get add operations too When an add for biblio or item is recorded there is no space in the info field Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> *** Bug 12235 has been marked as a duplicate of this bug. *** Created attachment 97147 [details] [review] Bug 10352: Display the correct modification logs for bibliographic records The 'Modification log" link in the cataloguing module returns confusing results. The 'object' parameter is the biblionumber, but the all log from itemnumber=biblionumber will be displayed as well. Since bug 11473 we have the action_logs.info column that is prefixed by 'item ' or 'biblio ' to disociated an item modification from a biblio modif. This patch suggests a quick and dirty approach, use this column to make sure we are searching for the correct logs. /!\ As bug 11473 did not update the existing rows, we will no longer display the logs created prior to this change. Test plan: Make sure you have at least 2 bibliographic records with some items Make sure you have the biblionumbers of those records that match existing itemnumbers Edit them (no matter what you change) Go to the bibliographic detail page (staff) and click "Modification log" You should see the correct changes. Signed-off-by: hc <hc@interleaf.ie> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 97148 [details] [review] Bug 10352: Use a new object_type parameter instead of the module's name To dissociate a search on biblio and item, we pass a new "object_type" parameter to viewlog.pl. If equals 'biblio' we will assume that "object" contains a biblionumber Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 97149 [details] [review] Bug 10352: (follow-up) show the biblionumber for items in modification logs This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious To test: 1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber i.e. In the sample data: biblionumber 59 with item with itemnumber 127 item with itemnumber 59 on biblionumber 23 2 - Edit both items however you wish 3 - On biblionumber 59 click the modification log 4 - You should see "Item 127" 5 - Click "Submit" on the form - this searches as itemnumber 6 - You should see "Item 59" 7 - Apply patch 8 - On biblionumber 59 click the modification log 9 - You should see "Item 127 from Biblio 59" 10 - Click "Submit" on the form - this searches as itemnumber 11 - You should see "Item 59 from Biblio 23" Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 97150 [details] [review] Bug 10352: Get add operations too When an add for biblio or item is recorded there is no space in the info field Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Nice work everyone! Pushed to master for 20.05 Pushed to 19.11.x branch for 19.11.03 backported to 19.05.x for 19.05.08 Enhancement will not be backported to 18.11.x series. |