After upgrade to 3.16, I've seen two partners who have the 'Email' check-box missing in the 'Patron Messaging Preferences' area on moremember.pl. There is a '-' where the check box should appear.
Additional research shows that message_transports does not have a row containing letter_code='HOLD' and message_transport_type='email'. I don't know what message_transports looked like prior to the 3.16 upgrade, but I did see that there were email messages in message_queue of type 'HOLD'. I suspect that update_database.pl may have caused the issue, but I don't have proof.
I am seeing the same thing happen at a different library; this time on PREDUEDGST. Note that this occurred significantly after the upgrade to 3.16, so I don't think that we're looking at an issue with update_database.pl
Have you still the problem? If yes, please paste the return for the following mysql command: select * from message_transports;
We ran into the same problem: After updating from 3.12.09 to 3.18.5.1 the table message_transports is missing all entries for the HOLD notice, resulting in the checkbox missing from the interface.
We updated over 15 installations now and the problem only appeared once. It might depend on the version the database started with or something in configuration.
Ok, lowering the priority but let it open to try and get more information.
Some instructions on how to fix this if you run into it: Check if there are entries for HOLD in the message_transports table: select * from message_transports If they are missing, run the following update: INSERT INTO message_transports (message_attribute_id, message_transport_type, is_digest, letter_module, letter_code) VALUES (4, 'email', 0, 'reserves', 'HOLD'), (4, 'sms', 0, 'reserves', 'HOLD'); The checkbox should show up again.
Is this bug still valid?
(In reply to Marc Véron from comment #8) > Is this bug still valid? I don't think that I've seen it happen since 3.16 -- given that we have a work-around in the form of the inserts into message_transports, I'm happy to close; we can re-open later if necessary. I suspect that the original issue happened due to a cascading delete on the 'letter' table. I'm closing the bug, if it pops up again, we can always re-open.
Hi, I repeat this problem on 16.11 Test plan: - in notice HOLD (/tools/letter.pl), write text in Print tab, save - check in table message_transports that line for HOLD are present (select * from message_transports) - in notice HOLD, supress text in Print tab, save - check in table message_transport that lines for HOLD are missing and in Patron messaging Preferences, there is a "-" where check box should appear Regards Marjorie
Hi Marjorie, the problem is we could never figure out why this happens - we have about 20 'identical' installations with Koha, but it only happend to us once or twice when updating. I'd recommend running the fix in comment#7 for now.
(In reply to Marjorie Barry-Vila from comment #10) > Hi, > > I repeat this problem on 16.11 > > Test plan: > > - in notice HOLD (/tools/letter.pl), write text in Print tab, save > - check in table message_transports that line for HOLD are present (select * > from message_transports) > - in notice HOLD, supress text in Print tab, save > - check in table message_transport that lines for HOLD are missing and in > Patron messaging Preferences, there is a "-" where check box should appear > > Regards > Marjorie Hi Marjorie, I have tried to replicate the problem following your test plan, but it didn't work for me on master. After emptying out the print section of the HOLD template, the checkboxes still appear normally for me. Maybe this is specific to 16.11, but can't test there right now.
Tested on 16.11.13.000, still not able to confirm :(
Katrin, I believe that what's happening here is that when rows are deleted from the letter table, there's a cascading delete on message_transports. There's a foreign key relationship between letter and message_transports, but the keys aren't entirely constrained... so deleting *any* row in the letter table will delete the rows in the message_transports with that letter code. At the time that this was discussed, this wasn't seen as a big deal, because the only way this could happen through the GUI was to delete the entire message, in which case the row would need to be removed from message_transports anyway. Unfortunately this didn't take upgradedatabase into account, and I think that we've seen this happen a couple of times because of that. --Barton
Hi Barton, can you reproduce the issue? HOLD can't be deleted from the GUI atm.
I'm noticing missing rows in the message_transports tables but no idea why yet. Mostly seems to be SMS for an old Koha that has been upgraded progressively over the years.
I know there was some problematic update in one of the earlier versions that left you with incomplete entries in the messaging preferences tables, but it happened very rarely and not consistently for every installation. I believe given to age and it not being a reoccuring event, we can close this. Please reopen if you disagree.