Add support for including fields from the Issues table in advanced due notices. This is primarily to allow the inclusion of the due date for each item in the advanced due notice, but will allow the inclusion of any field from the ISSUES table. This also adds code to exclude timestamp fields as these are irrelevant to the end user in this context.
Related patches can be picked up here: http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=shortlog;h=refs/heads/k_bug_5263
Does not apply: Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y Applying: Bug 5263 - Add support for including fields from the ISSUES table in advanced due notices Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging C4/Letters.pm CONFLICT (content): Merge conflict in C4/Letters.pm Auto-merging tools/letter.pl Failed to merge in the changes. Patch failed at 0001 Bug 5263 - Add support for including fields from the ISSUES table in advanced due notices When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". nengard@debian:~/kohaclone$
Created attachment 4583 [details] [review] Bug 5263 - Add support for including fields from the ISSUES table in advanced due notices Adding support for including fields from the Issues table in advanced due notices. This is primarily to allow the inclusion of the due date for each item in the advanced due notice, but will allow the inclusion of any field from the ISSUES table. This also adds code to exclude timestamp fields as these are irrelevant to the end user in this context. Note: Documentation should be updated to reflect the availability of the additional fields in all circulation notices.
The patch applies and the fields are available, but I added the due date and the issuedate to the checkout notice and instead of values showing I saw <> and <> for the two values I tried to add. Is there another way to test this? Nicole
I checked both PREDUE and PREDUEDGST with following results: PREDUE notice: borrowernumber <<issues.borrowernumber>> itemnumber <<issues.itemnumber>> date_due <<issues.date_due>> branchcode <<issues.branchcode>> issuingbranch <<issues.issuingbranch>> returndate <<issues.returndate>> lastrenewddate <<issues.lastreneweddate>> return <<issues.return>> renewals <<issues.renewals>> issuedate <<issues.issuedate>> PREDUE result: borrowernumber 19 itemnumber 8 date_due 2011-07-18 branchcode MPL issuingbranch returndate lastrnewddate return renewals issuedate 2011-07-17 RESULT: OK - Improvement, but date formatting is wrong. PREDUEDGST: <<items.content>> ./misc/cronjobs/advance_notices.pl -i date_due,branchcode,itemnumber,borrowernumber,issuedate PREDUEDGST: 07/18/2011 MPL 8 19 07/17/2011 RESULT: OK - Date formatting is correct too. I am signing off.
Created attachment 4648 [details] [review] [SIGNED-OFF] Bug 5263 - Add support for including fields from the ISSUES table in advanced due notices Adding support for including fields from the Issues table in advanced due notices. This is primarily to allow the inclusion of the due date for each item in the advanced due notice, but will allow the inclusion of any field from the ISSUES table. This also adds code to exclude timestamp fields as these are irrelevant to the end user in this context. Note: Documentation should be updated to reflect the availability of the additional fields in all circulation notices. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Pushed to master, please test
This patch has the items table being parsed with biblionumber as Key, which will result in all item information being wrong, unless itemnumber happens to equal biblionumber. Marking this as Failed QA, though it's a little late. I'll work on the fix and submit as a followup.
Created attachment 5678 [details] [review] Follow up Patch Fixes the issue introduced by the original patch of the items table being keyed in using the biblionumber
Pushed the follow up, please test again
There have been no further reports of problems so I am marking this bug resolved.