This was caused by bug 30555: When we insert new entries into the letters table for existing notices (new transport types), we need to make sure that letter.name of the old and new notice entries match. Otherwise we'll see 2 entries in the editor with no way to fix it from the GUI. Both lead to the same notice entry page. name gets translated, so we need to query the existing one with the code of the letter and use it for the new entries. To test: * You will need a non-English installation, with translated installer. de-DE would work. And where the database from bug 30555 has run. * Alternatively you can try and update the name field for one of the entries in letter manually to see the same effect. * Go to tools > notices and slips * Verify there are 2 entries for the DUEDGST and other notices with different description. * When editing, you should see the same text/entries for each. It's also the same URL.
I think the grouping should probably be on something else than the name (the letter code??). In my SQL files for translating db updates, I added a line to update the letter name in the english letter to the french name to counter this.
I think it's because it displays the title in the table, so when we group on the other criteria you get them as separate entries. It's easy to fix if you have db access, much harder for everyone else. Might still be good to do some clean-up.
Now this also happens when the name of a notice is updated in the GUI, which makes this a much less avoidable issue :(
*** This bug has been marked as a duplicate of bug 37891 ***
Putting this back to 'NEW' as discussion here appears to go more in-depth than what's being fixed in bug 37891.
(In reply to Caroline Cyr La Rose from comment #1) > I think the grouping should probably be on something else than the name (the > letter code??). > > In my SQL files for translating db updates, I added a line to update the > letter name in the english letter to the french name to counter this. The grouping is using name due to ONLY_FULL_GROUP_BY. Mattermost discussion: https://chat.koha-community.org/koha-community/pl/5xmw3emh9bduxbm51fkcg34k9y
(In reply to Katrin Fischer from comment #3) > Now this also happens when the name of a notice is updated in the GUI, which > makes this a much less avoidable issue :( Bug 37891 should fix that.
I've updated the bug title, but I'm open to better suggestions. I believe the table will show duplicate entries of notices if any of the following fields mismatch across the different instances of message_transport_type for each code (letter.pl): GROUP BY branchcode,module,code,name,branchname This should ideally no longer be reproduceable through the UI after bug 37891, but it is still possible by updating the database manually to meet these conditions, and there are possibly active Koha instances with this problem currently. Mattermost initial discussion (for bug 37891) but it applies here also: https://chat.koha-community.org/koha-community/pl/dqheyewpd7nqfjwom8f8khom7w