Created attachment 144756 [details]
Result show Error 500
Created attachment 144757 [details]
Result show Error 500
Update attachment
Created attachment 144758 [details]
Select Collection, Shelving location, Home library or Holding library
Update where select Collection, Shelving location, Home library or Holding library
This bug or not? I believe I'm seeing the same thing: CGI::Compile::ROOT::kohadevbox_koha_reports_issues_stats_2epl::calculate(): DBI Exception: DBD::mysql::st execute failed: The used SELECT statements have a different number of columns at /kohadevbox/koha/reports/issues_stats.pl line 92 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 We have it in 22.05.06 Created attachment 145637 [details] [review] Bug 32511: Circulation statistics result Error 500 where select Collection, Shelving location, Home library or Holding library Circulation statistics show error 500 when the tables 'items' and 'deleteditems' do not have the same number of columns. The error 'The used SELECT statements have a different number of columns' is shown in apache log. This patch resolvs the problem by selecting the common columns before execute the 'UNION' operator. To Test 1. In Staff interface, click on Reports module 2. Click on Circulation 3. Fill the form Period: Click on 'Row' and Select a date interval 4. Click on 'Submit' --> Koha gives a 500 error message 5. Apply the patch 6. Repeat step 1,2,3,4 --> There's no more error Hi,
I did :
1. In Staff interface, click on Reports module
2. Click on Circulation
3. Fill the form
Period: Click on 'Row' and Select a date interval
4. Click on 'Submit'
--> Koha gives a 500 error message
5. Apply the patch
6. Repeat step 1,2,3,4
--> Same error occurred.
Maybe there is something else needed ?
Created attachment 145661 [details] Circulation statistics result after test (In reply to Hammat wele from comment #7) > Created attachment 145637 [details] [review] [review] > Bug 32511: Circulation statistics result Error 500 where select Collection, > Shelving location, Home library or Holding library > > Circulation statistics show error 500 when the tables 'items' and > 'deleteditems' do not have the same number of columns. The error 'The used > SELECT statements have a different number of columns' is shown in apache log. > > This patch resolvs the problem by selecting the common columns before > execute the 'UNION' operator. > > To Test > > 1. In Staff interface, click on Reports module > 2. Click on Circulation > 3. Fill the form > Period: Click on 'Row' and Select a date interval > 4. Click on 'Submit' > --> Koha gives a 500 error message > 5. Apply the patch > 6. Repeat step 1,2,3,4 > --> There's no more error Patch tested by me with my database on Koha 22.11.01. All work! Signed-off-by: Mohd Hafiz Yusoff <mhby87@gmail.com> Patch tested by me with my database on Koha 22.11.01. All work! Signed-off-by: Mohd Hafiz Yusoff <mhby87@gmail.com> Created attachment 145662 [details] [review] Bug 32511: Circulation statistics result Error 500 where select Collection, Shelving location, Home library or Holding library Circulation statistics show error 500 when the tables 'items' and 'deleteditems' do not have the same number of columns. The error 'The used SELECT statements have a different number of columns' is shown in apache log. This patch resolvs the problem by selecting the common columns before execute the 'UNION' operator. To Test 1. In Staff interface, click on Reports module 2. Click on Circulation 3. Fill the form Period: Click on 'Row' and Select a date interval 4. Click on 'Submit' --> Koha gives a 500 error message 5. Apply the patch 6. Repeat step 1,2,3,4 --> There's no more error Signed-off-by: Mohd Hafiz Yusoff <mhby87@gmail.com> Created attachment 145694 [details] [review] Bug 17649: Only one message per borrower and overdue level The added option (-a|--all_in_one) allows to create only one message per borrower and delay level including overdues from whatever branches. A branchcode value (branches.branchcode) has to be given to choose which sender address will be set. == test plan == 0/ Have (or create) at least two branches B1 and B2. Have (or create) a default notice for all branches in Notices and Slips Module 1/ Make sure you're logged in with an account belonging to B1, or switch to branch B1 2/ checkout item I1 (belonging to B1) to patron P (specifying as due date the day before (1 day overdue)) 3/ switch to branch B2 4/ checkout item I2 (belonging to B2) to patron P (specifying as due date the day before (1 day overdue)) 5/ make sure you have defined "Overdue notice/status triggers" for that patron category, ie with Delay=1 so that "Overdue Notice" is selected and "Email" is checked. 6/ from cli run 'perl ./misc/cronjobs/overdue_notices.pl' (optionally specifying also '-library B1 -library B2' ) 7/ Two new entries will be generated in message_queue DB table, coming from different branches that have the SAME list of overdue items 8/ either see the 'content' field in these entries, or run 'perl ./cronjobs/process_message_queue.pl' to receive the actual emails (provided the email is properly setup). Apply patch redo step 6 running the script with the new option -a (all_in_one). this option expect as mandatory parameter the branchcode of the library that you want to make sender of the message. say that 'B2CODE' is the branchcode of B2 branch, it will run like this : perl ./misc/cronjobs/overdue_notices.pl -a B2CODE You will see that only one message had been created. Its content shows both B1 and B2 overdue items and the sender address matches B2 address as well. > Circulation statistics show error 500 when the tables 'items' and 'deleteditems' do not have the same number of columns. How can this be ? On item deletion we move datas from items to deleteditems via Koha::Items move_to_deleted() : https://git.koha-community.org/Koha-community/Koha/src/commit/1b6e9c7bd1c6e50ab610c6d15fe2e46af2f666ec/Koha/Item.pm#L332 Maybe linked to Bug 30392 ? But I dont se how it can go wrong. See also Bug 21982 On current master, I have a different error message : CGI::Compile::ROOT::kohadevbox_koha_reports_issues_stats_2epl::calculate(): DBI Exception: DBD::mysql::st execute failed: 'koha_kohadev.statistics.datetime' isn't in GROUP BY at /kohadevbox/koha/reports/issues_stats.pl line 92 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 This patch does not seem to be the correct fix. The columns in items and deleteditems are supposed to be the same, if you have a mismatch then you must fix the DB structure. Did you compare both table structures? (In reply to Jonathan Druart from comment #17) > This patch does not seem to be the correct fix. The columns in items and > deleteditems are supposed to be the same, if you have a mismatch then you > must fix the DB structure. > > Did you compare both table structures? Patch working at me, but this discussion Failed QA. How to fix DB structures or compare table structures. Tq (In reply to Fridolin Somers from comment #14) > Maybe linked to Bug 30392 ? > > But I dont se how it can go wrong. I don't know how, but in some case the colomn number of items and deleteditems are not the same. I have compared both tables and notice that the 'deleted_on' column is missing in the deleteditems table (in our case in 22.05.06). You right! there's already a bugzilla for this. (In reply to Hammat wele from comment #19) > (In reply to Fridolin Somers from comment #14) > > Maybe linked to Bug 30392 ? > > > > But I dont se how it can go wrong. > > I don't know how, but in some case the colomn number of items and > deleteditems are not the same. I have compared both tables and notice that > the 'deleted_on' column is missing in the deleteditems table (in our case in > 22.05.06). > > You right! there's already a bugzilla for this. Do you know the number? That one should especially be available in deleteditems and we need to figure out what happened there. Either the update patch didn't work... or something got backported that had it without the change in the db? > Do you know the number?
>
> That one should especially be available in deleteditems and we need to
> figure out what happened there.
>
> Either the update patch didn't work... or something got backported that had
> it without the change in the db?
The items table has 46 columns and the deleteditems has 45 columns. I think there should be something backported without updating the Database as you said.
After applying the patch 30392 and executing the ./installer/data/mysql/updatedatabase.pl. both tables have the same number of columns (46) and there is no more error
(In reply to Hammat wele from comment #21) > > Do you know the number? > > > > That one should especially be available in deleteditems and we need to > > figure out what happened there. > > > > Either the update patch didn't work... or something got backported that had > > it without the change in the db? > > The items table has 46 columns and the deleteditems has 45 columns. Which column was missing? Which version of Koha? (In reply to Jonathan Druart from comment #22) > (In reply to Hammat wele from comment #21) > > > Do you know the number? > > > > > > That one should especially be available in deleteditems and we need to > > > figure out what happened there. > > > > > > Either the update patch didn't work... or something got backported that had > > > it without the change in the db? > > > > The items table has 46 columns and the deleteditems has 45 columns. > > Which column was missing? Which version of Koha? The 'deleted_on' column was missing in the deleteditems table (In reply to Jonathan Druart from comment #22) > (In reply to Hammat wele from comment #21) > > > Do you know the number? > > > > > > That one should especially be available in deleteditems and we need to > > > figure out what happened there. > > > > > > Either the update patch didn't work... or something got backported that had > > > it without the change in the db? > > > > The items table has 46 columns and the deleteditems has 45 columns. > > Which column was missing? Which version of Koha? In my local test database, I intentionally deleted the `deleted_on` column to be able to reproduce the problem. I got the database structure on which @blou detected the problem (in Comment 6 ) and the missing column in the deleteditems table is a column named `paidfor` which is not present in the items table. I think we added the `paidfor` column in items table and didn't to add it in deleteditems table. that's where the problem came from. > I think we added the `paidfor` column in items table and didn't to add it in > deleteditems table. that's where the problem came from. Hi Hammat, that's interesting. paidfor used to be a field in items, but was removed quite some time ago. See here: Bug 26268 - Remove items.paid for once and for all So probably not a local customization, but something gone wrong in an update quite a while ago? Should we then close this bug maybe? Hello Katrin, Yes, please mark as INVALID. I came to the same conclusion, probably an update that failed when we moved to 21.05 (I see the change in 20.06 pile...) (In reply to Blou from comment #26) > Hello Katrin, > > Yes, please mark as INVALID. I came to the same conclusion, probably an > update that failed when we moved to 21.05 (I see the change in 20.06 pile...) Thx, Blou. Done. (In reply to Katrin Fischer from comment #27) > (In reply to Blou from comment #26) > > Hello Katrin, > > > > Yes, please mark as INVALID. I came to the same conclusion, probably an > > update that failed when we moved to 21.05 (I see the change in 20.06 pile...) > > Thx, Blou. Done. Remark as INVALID, any update can solve my problem? (In reply to Mohd Hafiz Yusoff from comment #28) > (In reply to Katrin Fischer from comment #27) > > (In reply to Blou from comment #26) > > > Hello Katrin, > > > > > > Yes, please mark as INVALID. I came to the same conclusion, probably an > > > update that failed when we moved to 21.05 (I see the change in 20.06 pile...) > > > > Thx, Blou. Done. > > Remark as INVALID, any update can solve my problem? You'll need to compare the tables items and deleteditems in your database as a first step. If you also have the paidfor column still and that is the only difference, check if anything is stored in that column. If not, delete it. (In reply to Katrin Fischer from comment #29) > (In reply to Mohd Hafiz Yusoff from comment #28) > > (In reply to Katrin Fischer from comment #27) > > > (In reply to Blou from comment #26) > > > > Hello Katrin, > > > > > > > > Yes, please mark as INVALID. I came to the same conclusion, probably an > > > > update that failed when we moved to 21.05 (I see the change in 20.06 pile...) > > > > > > Thx, Blou. Done. > > > > Remark as INVALID, any update can solve my problem? > > You'll need to compare the tables items and deleteditems in your database as > a first step. If you also have the paidfor column still and that is the only > difference, check if anything is stored in that column. If not, delete it. ... and always do a backup before any such 'operations'. (In reply to Katrin Fischer from comment #29) > (In reply to Mohd Hafiz Yusoff from comment #28) > > (In reply to Katrin Fischer from comment #27) > > > (In reply to Blou from comment #26) > > > > Hello Katrin, > > > > > > > > Yes, please mark as INVALID. I came to the same conclusion, probably an > > > > update that failed when we moved to 21.05 (I see the change in 20.06 pile...) > > > > > > Thx, Blou. Done. > > > > Remark as INVALID, any update can solve my problem? > > You'll need to compare the tables items and deleteditems in your database as > a first step. If you also have the paidfor column still and that is the only > difference, check if anything is stored in that column. If not, delete it. Yes, in table items has a column paidfor. I delete column paidfor, and its work. ALTER TABLE items DROP COLUMN paidfor; Thank you all. |
Created attachment 144755 [details] Select selving location After upgrade from koha 22.05 to 22.11, Circulation statistics show error 500 result when select Shelving location