Now that the 'News' tool serves a larger purpose than just adding news, we should rename it. I suggest 'Content' or 'Custom content'. But it's just a suggestion. Feel free to change it to something else.
Maybe "News and content" ? It's technically redundant but I worry that people will wonder where News went.
*** Bug 25001 has been marked as a duplicate of this bug. ***
As I mention on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25001, it seems the CMS functionality will use a heading of "Pages" with a description of "Create and edit additional content pages". I've asked one librarian and they suggested "Interface customization" or "Home page customization" or something like that. Martin suggested "Blocks" or "Content blocks", which I quite like, since it implies that it's chunks of content rather than whole pages (like the CMS), but I don't think librarians will understand. Maybe "HTML customization"? But that would only work for tech savvy librarians. Maybe "Web page customization" or "Page customization", but then I worry about the overlap with the CMS functionality. That said, maybe we should frame it all with a "Edit content" or "Content" heading and then have subheadings for "Pages" and "Sections"?
(In reply to Owen Leonard from comment #1) > Maybe "News and content" ? > > It's technically redundant but I worry that people will wonder where News > went. +1 We still use this for news and I think it would confuse some of our folks who use that feature.
Some librarians use a lot of News items (both in slips and in the the OPAC ). That makes for a lot of clutter once we start adding the HTML preferences. What are the thoughts of separating these into separate 'Tools'? -News -Another section for "HTML customization" or whatever is decided to call it
(In reply to Lucas Gass from comment #5) > Some librarians use a lot of News items (both in slips and in the the OPAC > ). That makes for a lot of clutter once we start adding the HTML > preferences. What are the thoughts of separating these into separate 'Tools'? > > -News > -Another section for "HTML customization" or whatever is decided to call it This is even better. Especially in consortium where different libraries might all be using the news for different things, it could be very clunky to have all the news + these content fields we are moving into the news.
I support separating news and html customizations.
(In reply to Lucas Gass from comment #5) > Some librarians use a lot of News items (both in slips and in the the OPAC > ). That makes for a lot of clutter once we start adding the HTML > preferences. What are the thoughts of separating these into separate 'Tools'? > > -News > -Another section for "HTML customization" or whatever is decided to call it +1 to separate them !
+1 to separating them. News is extremely cluttered now (as a consortium).
Please help bug 22544 if you want to see this move forward.
I am suggesting: * Codebase will use "additional_contents", Koha::AdditionalContents * UI will split: Tools > News (same as now) Tools > HTML customization Would that work for everybody?
(In reply to Jonathan Druart from comment #11) > I am suggesting: > > * Codebase will use "additional_contents", Koha::AdditionalContents > > * UI will split: > Tools > News (same as now) > Tools > HTML customization > > Would that work for everybody? +1
Created attachment 122737 [details] [review] Bug 24387: Rename "News" with "Additional contents" One big patch for one big move. The "News" feature (opac_news) has been hijacked to handle some system preferences (bug 26050). The goal was to take profit of the UI (editor) and the ability to translate the value. Disclaimer: This patch is NOT offering the best implementation but, as we still don't have bug 24975, it cannot be done now. And no, we don't want to wait for it to move forward here. This patch is going into the right direction anyway. This enhancement is going to rename the "News" with a more genertic "Additional contents". We have two different "categories" of content: "news" and "html customizations". What does it bring? - A split on the UI for disambigate the two types of content (news and syspref/html customizations) - A simplification of the edit form: all languages will be translatable on the same view (like the "notice templates") - Ground will be prepared for different types of content (if needed later) - Staff news can be translated How was the "News" area working before this patch? The opac_news DB table contained a (very inconsistent) 'lang' column. The different values were: - '' => news to display at the OPAC and staff interfaces - 'koha' => news for staff only - 'slip' => news for slip notices - $lang => news for OPAC only, translated in $lang ('en', 'es-ES', etc.) - "$location_$lang" => A syspref moved to this "news" area. The syspref is $location, and is translated in $lang. Eg. OpacLoginInstructions_en, OpacLoginInstructions_fr-FR, opacheader_es-ES This patch is improving the DB structure with the following changes: - renaming 'opac_news' with 'additional_contents' - new 'category' column => 'news' or 'html_customizations' - new 'location' column => For 'news': 'staff_and_opac', 'staff_only', 'slip' => For 'html_customizations': the old syspref name (eg. 'OpacLoginInstructions'). - new 'code' column (see later for more info) - the 'lang' column will only contain the language code ('en', 'es-ES', etc.). BUT a 'default' entry will ALWAYS exist for fallback behaviour. We are getting closer to the 'notice template' table structure because we want to match its UI. The 'code' column will bring us the ability to group the different 'additional_contents' rows. The code for a given news will be the same, but the (lang, title, content) will differ. Examples: News 1 will have, for each of the translated versions (category, code, location, branchcode) ('news', 'News1', $location, $branchcode||undef) And the 3 following columns will differ: (title, content, lang) ('title for news 1', 'content for news 1', 'default') ('titulo para 1', 'contenido para 1', 'es-ES') Note that the "category" is not strictely necessary, but it seems better to have the ability to split the different content by category/type easily. Additional changes: - Syspref 'NewsToolEditor' is renamed 'AdditionalContentsEditor' - Koha::NewItem => Koha::AdditionalContent - Koha::News => Koha::AdditionalContents - Script and template renamed from koha-news to additional-contents - Foreign keys have been renamed - Subpermission edit_news has been renamed edit_additional_contents - The UI can now be accessed via a "News" or "HTML customizations" link from the tools module. The related contents will then be displayed (both categories are now split) Changes not done here: - Primary key 'idnew' could be renamed 'id' Limitations of the upgrade: News cannot be grouped by a unique code for existing translations. => A given news will be now displayed several times on the translated interface Any ideas to improve the upgrade behaviour? We will have to add a warning in the release notes to tell libraries to review their news. Test plan: 0. Don't apply the patches 1. Translate the interfaces in some languages . Create some news for staff and OPAC . Create some content for different entry of HTML customizations Note that you are forced to define a 'default'. Also note that you are only forced to fill the title (not the content). This is certainly problematic (see FIXME in the code) as sometime only the content is displayed. . Play with the interface (edit, delete, filter) . Go to the different places the news are displayed, and confirm they are displayed correctly (staff home, opac home, opac rss) . Create 1+ news for 'slip', check an item out and 'print slip' (from the circulation page). You must see the news. . Go to the different places you are expecting the HTML customizations to be present and confirm that you see them. . Switch the lang of the interface and confirm that you now see the content in the translated version . Generate the templates in another language, don't translate the content . Use this language for the interface and confirm that the 'default' version is displauyed.
Created attachment 122738 [details] [review] Bug 24387: DBIC Schema changes DBIC update dbic update
Some screenshots: https://snipboard.io/WspLi3.jpg https://snipboard.io/XRE3Mq.jpg https://snipboard.io/z3UY5q.jpg https://snipboard.io/oa7LQf.jpg https://snipboard.io/lYPyjw.jpg
I still prefer 'Blocks' or 'Content blocks' but am happy to be overruled there. However, this isn't working fully for me.. in the HTML Customisations screen if I attempt to edit an existing block the Display locations dropdown only shows the News options and not the Nav blocks etc. As later change, I'd love to see a more visual display on the blocks page highlighting where the blocks of content will actually appear rather than just a table.. but that's certainly a later enhancement.
(In reply to Martin Renvoize from comment #16) > I still prefer 'Blocks' or 'Content blocks' but am happy to be overruled > there. Well, Katrin disagreed on that one, and that's why I've asked here before starting two days ago! :D Now it will be quite a nightmare to replace all the occurrences (script and template names, DB table, variables, modules...) > However, this isn't working fully for me.. in the HTML Customisations screen > if I attempt to edit an existing block the Display locations dropdown only > shows the News options and not the Nav blocks etc. Indeed, patch on its way! > As later change, I'd love to see a more visual display on the blocks page > highlighting where the blocks of content will actually appear rather than > just a table.. but that's certainly a later enhancement. Can you detail?
Created attachment 122746 [details] [review] Bug 24387: Fix location options when editing HTML custom
And I finally forgot to write those tests for search_for_display! Will do next week if I don't forget. It does not prevent testing ;)
Created attachment 122748 [details] Dump of dumb data for opac_news to replay the db rev easily
*** Bug 27451 has been marked as a duplicate of this bug. ***
*** Bug 22663 has been marked as a duplicate of this bug. ***
*** Bug 24766 has been marked as a duplicate of this bug. ***
Created attachment 122872 [details] [review] Bug 24387: Rename "News" with "Additional contents" One big patch for one big move. The "News" feature (opac_news) has been hijacked to handle some system preferences (bug 26050). The goal was to take profit of the UI (editor) and the ability to translate the value. Disclaimer: This patch is NOT offering the best implementation but, as we still don't have bug 24975, it cannot be done now. And no, we don't want to wait for it to move forward here. This patch is going into the right direction anyway. This enhancement is going to rename the "News" with a more genertic "Additional contents". We have two different "categories" of content: "news" and "html customizations". What does it bring? - A split on the UI for disambigate the two types of content (news and syspref/html customizations) - A simplification of the edit form: all languages will be translatable on the same view (like the "notice templates") - Ground will be prepared for different types of content (if needed later) - Staff news can be translated How was the "News" area working before this patch? The opac_news DB table contained a (very inconsistent) 'lang' column. The different values were: - '' => news to display at the OPAC and staff interfaces - 'koha' => news for staff only - 'slip' => news for slip notices - $lang => news for OPAC only, translated in $lang ('en', 'es-ES', etc.) - "$location_$lang" => A syspref moved to this "news" area. The syspref is $location, and is translated in $lang. Eg. OpacLoginInstructions_en, OpacLoginInstructions_fr-FR, opacheader_es-ES This patch is improving the DB structure with the following changes: - renaming 'opac_news' with 'additional_contents' - new 'category' column => 'news' or 'html_customizations' - new 'location' column => For 'news': 'staff_and_opac', 'staff_only', 'slip' => For 'html_customizations': the old syspref name (eg. 'OpacLoginInstructions'). - new 'code' column (see later for more info) - the 'lang' column will only contain the language code ('en', 'es-ES', etc.). BUT a 'default' entry will ALWAYS exist for fallback behaviour. We are getting closer to the 'notice template' table structure because we want to match its UI. The 'code' column will bring us the ability to group the different 'additional_contents' rows. The code for a given news will be the same, but the (lang, title, content) will differ. Examples: News 1 will have, for each of the translated versions (category, code, location, branchcode) ('news', 'News1', $location, $branchcode||undef) And the 3 following columns will differ: (title, content, lang) ('title for news 1', 'content for news 1', 'default') ('titulo para 1', 'contenido para 1', 'es-ES') Note that the "category" is not strictely necessary, but it seems better to have the ability to split the different content by category/type easily. Additional changes: - Syspref 'NewsToolEditor' is renamed 'AdditionalContentsEditor' - Koha::NewItem => Koha::AdditionalContent - Koha::News => Koha::AdditionalContents - Script and template renamed from koha-news to additional-contents - Foreign keys have been renamed - Subpermission edit_news has been renamed edit_additional_contents - The UI can now be accessed via a "News" or "HTML customizations" link from the tools module. The related contents will then be displayed (both categories are now split) Changes not done here: - Primary key 'idnew' could be renamed 'id' Limitations of the upgrade: News cannot be grouped by a unique code for existing translations. => A given news will be now displayed several times on the translated interface Any ideas to improve the upgrade behaviour? We will have to add a warning in the release notes to tell libraries to review their news. Test plan: 0. Don't apply the patches 1. Translate the interfaces in some languages . Create some news for staff and OPAC . Create some content for different entry of HTML customizations Note that you are forced to define a 'default'. Also note that you are only forced to fill the title (not the content). This is certainly problematic (see FIXME in the code) as sometime only the content is displayed. . Play with the interface (edit, delete, filter) . Go to the different places the news are displayed, and confirm they are displayed correctly (staff home, opac home, opac rss) . Create 1+ news for 'slip', check an item out and 'print slip' (from the circulation page). You must see the news. . Go to the different places you are expecting the HTML customizations to be present and confirm that you see them. . Switch the lang of the interface and confirm that you now see the content in the translated version . Generate the templates in another language, don't translate the content . Use this language for the interface and confirm that the 'default' version is displauyed.
Created attachment 122873 [details] [review] Bug 24387: Fix location options when editing HTML custom
Created attachment 122874 [details] [review] Bug 24387: DBIC schema changes
Created attachment 122878 [details] [review] Bug 24387: Rename "News" with "Additional contents" One big patch for one big move. The "News" feature (opac_news) has been hijacked to handle some system preferences (bug 26050). The goal was to take profit of the UI (editor) and the ability to translate the value. Disclaimer: This patch is NOT offering the best implementation but, as we still don't have bug 24975, it cannot be done now. And no, we don't want to wait for it to move forward here. This patch is going into the right direction anyway. This enhancement is going to rename the "News" with a more genertic "Additional contents". We have two different "categories" of content: "news" and "html customizations". What does it bring? - A split on the UI for disambigate the two types of content (news and syspref/html customizations) - A simplification of the edit form: all languages will be translatable on the same view (like the "notice templates") - Ground will be prepared for different types of content (if needed later) - Staff news can be translated How was the "News" area working before this patch? The opac_news DB table contained a (very inconsistent) 'lang' column. The different values were: - '' => news to display at the OPAC and staff interfaces - 'koha' => news for staff only - 'slip' => news for slip notices - $lang => news for OPAC only, translated in $lang ('en', 'es-ES', etc.) - "$location_$lang" => A syspref moved to this "news" area. The syspref is $location, and is translated in $lang. Eg. OpacLoginInstructions_en, OpacLoginInstructions_fr-FR, opacheader_es-ES This patch is improving the DB structure with the following changes: - renaming 'opac_news' with 'additional_contents' - new 'category' column => 'news' or 'html_customizations' - new 'location' column => For 'news': 'staff_and_opac', 'staff_only', 'slip' => For 'html_customizations': the old syspref name (eg. 'OpacLoginInstructions'). - new 'code' column (see later for more info) - the 'lang' column will only contain the language code ('en', 'es-ES', etc.). BUT a 'default' entry will ALWAYS exist for fallback behaviour. We are getting closer to the 'notice template' table structure because we want to match its UI. The 'code' column will bring us the ability to group the different 'additional_contents' rows. The code for a given news will be the same, but the (lang, title, content) will differ. Examples: News 1 will have, for each of the translated versions (category, code, location, branchcode) ('news', 'News1', $location, $branchcode||undef) And the 3 following columns will differ: (title, content, lang) ('title for news 1', 'content for news 1', 'default') ('titulo para 1', 'contenido para 1', 'es-ES') Note that the "category" is not strictely necessary, but it seems better to have the ability to split the different content by category/type easily. Additional changes: - Syspref 'NewsToolEditor' is renamed 'AdditionalContentsEditor' - Koha::NewItem => Koha::AdditionalContent - Koha::News => Koha::AdditionalContents - Script and template renamed from koha-news to additional-contents - Foreign keys have been renamed - Subpermission edit_news has been renamed edit_additional_contents - The UI can now be accessed via a "News" or "HTML customizations" link from the tools module. The related contents will then be displayed (both categories are now split) Changes not done here: - Primary key 'idnew' could be renamed 'id' Limitations of the upgrade: News cannot be grouped by a unique code for existing translations. => A given news will be now displayed several times on the translated interface Any ideas to improve the upgrade behaviour? We will have to add a warning in the release notes to tell libraries to review their news. Test plan: 0. Don't apply the patches 1. Translate the interfaces in some languages . Create some news for staff and OPAC . Create some content for different entry of HTML customizations Note that you are forced to define a 'default'. Also note that you are only forced to fill the title (not the content). This is certainly problematic (see FIXME in the code) as sometime only the content is displayed. . Play with the interface (edit, delete, filter) . Go to the different places the news are displayed, and confirm they are displayed correctly (staff home, opac home, opac rss) . Create 1+ news for 'slip', check an item out and 'print slip' (from the circulation page). You must see the news. . Go to the different places you are expecting the HTML customizations to be present and confirm that you see them. . Switch the lang of the interface and confirm that you now see the content in the translated version . Generate the templates in another language, don't translate the content . Use this language for the interface and confirm that the 'default' version is displauyed. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 122879 [details] [review] Bug 24387: Fix location options when editing HTML custom Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 122880 [details] [review] Bug 24387: DBIC schema changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This is a great improvement, the biggest bit to me being the 'default' fallback behaviour. I can't come up with a nicer way to do the DB update, but I think we can cover ourselves with release notes. We can certainly continue to iterate here on follow-up bugs.. I'm still keen to split the tables back out for different functions.. but that can certainly come later. Signing off.
Created attachment 123730 [details] [review] Bug 24387: Rename "News" with "Additional contents" One big patch for one big move. The "News" feature (opac_news) has been hijacked to handle some system preferences (bug 26050). The goal was to take profit of the UI (editor) and the ability to translate the value. Disclaimer: This patch is NOT offering the best implementation but, as we still don't have bug 24975, it cannot be done now. And no, we don't want to wait for it to move forward here. This patch is going into the right direction anyway. This enhancement is going to rename the "News" with a more genertic "Additional contents". We have two different "categories" of content: "news" and "html customizations". What does it bring? - A split on the UI for disambigate the two types of content (news and syspref/html customizations) - A simplification of the edit form: all languages will be translatable on the same view (like the "notice templates") - Ground will be prepared for different types of content (if needed later) - Staff news can be translated How was the "News" area working before this patch? The opac_news DB table contained a (very inconsistent) 'lang' column. The different values were: - '' => news to display at the OPAC and staff interfaces - 'koha' => news for staff only - 'slip' => news for slip notices - $lang => news for OPAC only, translated in $lang ('en', 'es-ES', etc.) - "$location_$lang" => A syspref moved to this "news" area. The syspref is $location, and is translated in $lang. Eg. OpacLoginInstructions_en, OpacLoginInstructions_fr-FR, opacheader_es-ES This patch is improving the DB structure with the following changes: - renaming 'opac_news' with 'additional_contents' - new 'category' column => 'news' or 'html_customizations' - new 'location' column => For 'news': 'staff_and_opac', 'staff_only', 'slip' => For 'html_customizations': the old syspref name (eg. 'OpacLoginInstructions'). - new 'code' column (see later for more info) - the 'lang' column will only contain the language code ('en', 'es-ES', etc.). BUT a 'default' entry will ALWAYS exist for fallback behaviour. We are getting closer to the 'notice template' table structure because we want to match its UI. The 'code' column will bring us the ability to group the different 'additional_contents' rows. The code for a given news will be the same, but the (lang, title, content) will differ. Examples: News 1 will have, for each of the translated versions (category, code, location, branchcode) ('news', 'News1', $location, $branchcode||undef) And the 3 following columns will differ: (title, content, lang) ('title for news 1', 'content for news 1', 'default') ('titulo para 1', 'contenido para 1', 'es-ES') Note that the "category" is not strictely necessary, but it seems better to have the ability to split the different content by category/type easily. Additional changes: - Syspref 'NewsToolEditor' is renamed 'AdditionalContentsEditor' - Koha::NewItem => Koha::AdditionalContent - Koha::News => Koha::AdditionalContents - Script and template renamed from koha-news to additional-contents - Foreign keys have been renamed - Subpermission edit_news has been renamed edit_additional_contents - The UI can now be accessed via a "News" or "HTML customizations" link from the tools module. The related contents will then be displayed (both categories are now split) Changes not done here: - Primary key 'idnew' could be renamed 'id' Limitations of the upgrade: News cannot be grouped by a unique code for existing translations. => A given news will be now displayed several times on the translated interface Any ideas to improve the upgrade behaviour? We will have to add a warning in the release notes to tell libraries to review their news. Test plan: 0. Don't apply the patches 1. Translate the interfaces in some languages . Create some news for staff and OPAC . Create some content for different entry of HTML customizations Note that you are forced to define a 'default'. Also note that you are only forced to fill the title (not the content). This is certainly problematic (see FIXME in the code) as sometime only the content is displayed. . Play with the interface (edit, delete, filter) . Go to the different places the news are displayed, and confirm they are displayed correctly (staff home, opac home, opac rss) . Create 1+ news for 'slip', check an item out and 'print slip' (from the circulation page). You must see the news. . Go to the different places you are expecting the HTML customizations to be present and confirm that you see them. . Switch the lang of the interface and confirm that you now see the content in the translated version . Generate the templates in another language, don't translate the content . Use this language for the interface and confirm that the 'default' version is displauyed. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 123731 [details] [review] Bug 24387: Fix location options when editing HTML custom Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 123732 [details] [review] Bug 24387: DBIC schema changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 123733 [details] [review] Bug 24387: (QA follow-up) Add missing filters Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 123734 [details] [review] Bug 24387: (QA follow-up) Fix method import issues Raised by the QA script, a couple issues carried by pre-17600 patches. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some DB columns are missing default values (category, code and location): DBD::mysql::db do failed: Field 'code' doesn't have a default value at /kohadevbox/koha/C4/Installer.pm line 572.
Created attachment 123795 [details] [review] Bug 24387: Fix sample_news.yml installer file
Created attachment 123796 [details] [review] Bug 24387: Remove sample_news.for other languages We shouldn't continue to update those files as we are going to remove them soon.
(In reply to Tomás Cohen Arazi from comment #36) > Some DB columns are missing default values (category, code and location): > > DBD::mysql::db do failed: Field 'code' doesn't have a default value at > /kohadevbox/koha/C4/Installer.pm line 572. It's the installer file that was missing values for those columns! Thx!
Created attachment 123797 [details] [review] Bug 24387: Fix sample_news.yml installer file Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 123798 [details] [review] Bug 24387: Remove sample_news.for other languages We shouldn't continue to update those files as we are going to remove them soon. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This action will erase all your data. Are you sure? (y/N) y Running [sudo koha-shell kohadev -p -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/koha/lib:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/populate_db.pl -v --opac-base-url http://kohadev.myDNSname.org:8080 --intranet-base-url http://kohadev-intra.myDNSname.org:8081 --marcflavour MARC21']... C4::Installer::load_sql returned the following errors while attempting to load /kohadevbox/koha/installer/data/mysql/en/optional/sample_news.yml: DBD::mysql::db do failed: Field 'code' doesn't have a default value at /kohadevbox/koha/C4/Installer.pm line 572. Inserting koha db structure...
With all the patches attached to the bug report right now: root@kohadevbox:koha(bug_24387)$ reset_all This action will erase all your data. Are you sure? (y/N) y Running [sudo koha-shell kohadev -p -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/koha/lib:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/populate_db.pl -v --opac-base-url http://kohadev.myDNSname.org:8080 --intr anet-base-url http://kohadev-intra.myDNSname.org:8081 --marcflavour MARC21']... Inserting koha db structure... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/sysprefs.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/subtag_registry.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/auth_val_cat.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/message_transport_types.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/sample_notices_message_attributes.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/sample_notices_message_transports.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/keyboard_shortcuts.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/userflags.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/userpermissions.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/audio_alerts.sql... Skipping /kohadevbox/koha/installer/data/mysql/account_offset_types.sql Inserting /kohadevbox/koha/installer/data/mysql/mandatory/account_credit_types.sql... Inserting /kohadevbox/koha/installer/data/mysql/mandatory/account_debit_types.sql... Inserting /kohadevbox/koha/installer/data/mysql/en/mandatory/auth_values.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/mandatory/class_sources.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/mandatory/sample_frequencies.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/mandatory/sample_notices.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/mandatory/sample_numberpatterns.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/auth_val.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/csv_profiles.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/marc21_holdings_coded_values.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/marc21_relatorterms.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/parameters.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/patron_atributes.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/patron_categories.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_creator_data.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_itemtypes.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_libraries.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_libraries_holidays.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_news.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_patrons.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_quotes.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/optional/sample_z3950_servers.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/marc21/mandatory/authorities_normal_marc21.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/marc21/optional/marc21_default_matching_rules.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/marc21/optional/marc21_sample_fastadd_framework.yml... Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/marc21/optional/marc21_simple_bib_frameworks.yml... Setting the MARC flavour on the sysprefs... Setting Koha version to 21.0600014... Can you double-check please?
My setup is KTD, using master-buster and mariadb:10.3
Created attachment 123803 [details] [review] Bug 24387: Fix sample_news.yml installer file
(In reply to Tomás Cohen Arazi from comment #44) > My setup is KTD, using master-buster and mariadb:10.3 Same here but with mariadb 10:1:48. The code was missing from yml, obvious mistake, sorry about that.
[ We should docker up "d11" and have a D11 with dbms version brought by D11 We shouldn't have to explicitly tell that we need to up with docker-compose.mariadb_d11.yml Can this be fixed? is it worth opening a new ktd issue? ]
Created attachment 123811 [details] [review] Bug 24387: Fix sample_news.yml installer file Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed to master for 21.11, thanks to everybody involved!
Created attachment 123854 [details] [review] Bug 24387: Fix one remaining occurrence of KohaNews
Created attachment 123855 [details] [review] Bug 24387: Fix AdditionalContents.t
Created attachment 123856 [details] [review] Bug 24387: Fix Letters/TemplateToolkit.t We must cast to date or the comparison does not work
Last 3 patches pushed to master.
Created attachment 124867 [details] [review] Bug 24387: Entries with parent are missing a code We executed the same 2 queries, we want to adjust the code for the parent and the language specific row.
Created attachment 125545 [details] [review] Bug 24387: Entries with parent are missing a code We executed the same 2 queries, we want to adjust the code for the parent and the language specific row. Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Jonathan Druart from comment #54) > Created attachment 124867 [details] [review] [review] > Bug 24387: Entries with parent are missing a code > > We executed the same 2 queries, we want to adjust the code for the > parent and the language specific row. (In reply to Nick Clemens from comment #55) > Created attachment 125545 [details] [review] [review] > Bug 24387: Entries with parent are missing a code > > We executed the same 2 queries, we want to adjust the code for the > parent and the language specific row. > > Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Read code, did not test, but the change makes logical sense
(In reply to Nick Clemens from comment #55) > Created attachment 125545 [details] [review] [review] > Bug 24387: Entries with parent are missing a code > > We executed the same 2 queries, we want to adjust the code for the > parent and the language specific row. > > Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Pushed to master.
(In reply to Tomás Cohen Arazi from comment #31) > Disclaimer: This patch is NOT offering the best implementation but, as > we still don't have bug 24975, it cannot be done now. And no, we don't > want to wait for it to move forward here. This patch is going into the > right direction anyway. 24975 wasnt there in August 2021, but still in coma October 2022..
+ $new_lang = "default" if $new_lang eq 'en'; # Assume that "en" is "default" Dont like this assumption after all ;)
(In reply to Marcel de Rooy from comment #59) > + $new_lang = "default" if $new_lang eq 'en'; # Assume that "en" is > "default" > > Dont like this assumption after all ;) This dbrev made a mess of my news items.
Same for us french. We fixed manually after upgrade.
(In reply to Fridolin Somers from comment #61) > Same for us french. > We fixed manually after upgrade. I don't know if it was this change, but we've had a lot of issues with news/additional contents with upgrades where we have multiple languages enabled. Manually fixed after upgrade as well.
What did you fix, and how?
(In reply to Jonathan Druart from comment #63) > What did you fix, and how? In short (but I spent a few hours): News goes fine, the non-News stuff goes wrong. If you have an EN and an NL record, it adds two Default records. The EN and NL are not connected anymore. This may lead to duplicating elements on the OPAC display too. Also EN became default iirc. I had to do a little bit more since I had customized news stuff too. So it made no sense to submit my fix.
(In reply to Jonathan Druart from comment #63) > What did you fix, and how? Same for us. And before upgrade we looked where custom block is only 'fr-FR' to change it in 'en'. So that is becomes default after upgrade.
(In reply to Jonathan Druart from comment #63) > What did you fix, and how? We ended up having to delete duplicated entries. I can't remember what conditions we used for the cleanup.
I'm trying to figure out how to NOT have to do manual changes after the upgrade as we're about to upgrade ~60 installations from 21.05 to 22.05. I have an instance with 4 'OpacMainUserBlock' news, two in fr-CA and two in en. They each are the translation of the other (i.e. en #1 is the translation of fr-CA #1 and en #2 is the translation of fr-CA #2). Although It's not evident in the db and I don't think the dbrev can do anything about it. (And what's worse is that this particular library just copied the French text into the english news... but we won't take that into account.) select idnew, branchcode, title, lang, published_on, updated_on, expirationdate, number, borrowernumber from opac_news where lang like "%OpacMainUserBlock%"; +-------+------------+-------------------------+-------------------------+--------------+---------------------+----------------+--------+----------------+ | idnew | branchcode | title | lang | published_on | updated_on | expirationdate | number | borrowernumber | +-------+------------+-------------------------+-------------------------+--------------+---------------------+----------------+--------+----------------+ | 19 | NULL | OpacMainUserBlock_fr-CA | OpacMainUserBlock_fr-CA | 2021-02-01 | 2022-09-27 11:49:20 | NULL | 0 | NULL | | 20 | NULL | OpacMainUserBlock_en | OpacMainUserBlock_en | 2021-02-01 | 2022-09-27 11:49:20 | NULL | 0 | NULL | | 31 | NULL | Ouverture | OpacMainUserBlock_fr-CA | 2021-06-22 | 2022-08-10 10:08:52 | NULL | 1 | 1 | | 32 | NULL | Welcome | OpacMainUserBlock_en | 2021-06-22 | 2022-08-10 10:08:52 | NULL | 1 | 1 | +-------+------------+-------------------------+-------------------------+--------------+---------------------+----------------+--------+----------------+ 4 rows in set (0.000 sec) After the upgrade, I have six 'OpacMainUserBlock' contents, four defaults and two fr-CA. It seems like it doubled the fr-CA ones (one default and one fr-CA for each) and changed the en ones into default. select idnew, category, code, location, branchcode, title, lang, published_on, expirationdate, number, borrowernumber from additional_contents where location = 'OpacMainUserBlock' order by code; +-------+---------------------+---------+-------------------+------------+-------------------------+---------+--------------+----------------+--------+----------------+ | idnew | category | code | location | branchcode | title | lang | published_on | expirationdate | number | borrowernumber | +-------+---------------------+---------+-------------------+------------+-------------------------+---------+--------------+----------------+--------+----------------+ | 20 | html_customizations | News_20 | OpacMainUserBlock | NULL | OpacMainUserBlock_en | default | 2021-02-01 | NULL | 0 | NULL | | 32 | html_customizations | News_32 | OpacMainUserBlock | NULL | Welcome | default | 2021-06-22 | NULL | 1 | 1 | | 19 | html_customizations | News_49 | OpacMainUserBlock | NULL | OpacMainUserBlock_fr-CA | fr-CA | 2021-02-01 | NULL | 0 | NULL | | 49 | html_customizations | News_49 | OpacMainUserBlock | NULL | OpacMainUserBlock_fr-CA | default | 2021-02-01 | NULL | 0 | NULL | | 31 | html_customizations | News_55 | OpacMainUserBlock | NULL | Ouverture | fr-CA | 2021-06-22 | NULL | 1 | 1 | | 55 | html_customizations | News_55 | OpacMainUserBlock | NULL | Ouverture | default | 2021-06-22 | NULL | 1 | 1 | +-------+---------------------+---------+-------------------+------------+-------------------------+---------+--------------+----------------+--------+----------------+ 6 rows in set (0.000 sec) The contents are doubled everywhere in the OPAC, both in English and French. So I think default appears no matter which language were on? I'm wondering if it's necessary to create defaults? It was not possible to have that before with the news, it had to be in either language. So I don't think it makes sense to create a default in the course of the upgrade... (It's fine to use default after of course).
Created attachment 142653 [details] [review] Bug 24387 - fixup to db_rev for non-english, multilingual Koha Without this patch, the update process duplicates all the news and content entries when they were non-english to start with. This patch keeps the same process, but new "default" "parent" entries are empty so there' no duplication in the OPAC display, while still being editable/deletable in the intranet. We came through that through many iterations. This was the least invasive while still providing satisfying results.
Thanks Blou! I've marked this as "additional_work_needed" to get some attention, but as this bug has already been released and we don't want it to show up in release notes again, we should move the follow-up to a separate bug where we can also highlight it as a fix for a bad bug.
(In reply to Katrin Fischer from comment #69) > Thanks Blou! I've marked this as "additional_work_needed" to get some > attention, but as this bug has already been released and we don't want it to > show up in release notes again, we should move the follow-up to a separate > bug where we can also highlight it as a fix for a bad bug. Moved to bug 32110 to get proper QA on it.
Comment on attachment 142653 [details] [review] Bug 24387 - fixup to db_rev for non-english, multilingual Koha >From 559376aaf1c53efa1589a37e77769c6ffc41088d Mon Sep 17 00:00:00 2001 >From: Blou <blou@inlibro.com> >Date: Tue, 25 Oct 2022 14:55:52 -0400 >Subject: [PATCH] Bug 24387 - fixup to db_rev for non-english, multilingual > Koha > >Without this patch, the update process duplicates all the news and >content entries when they were non-english to start with. > >This patch keeps the same process, but new "default" "parent" entries are empty so there' >no duplication in the OPAC display, while still being editable/deletable >in the intranet. > >We came through that through many iterations. This was the least >invasive while still providing satisfying results. >--- > installer/data/mysql/db_revs/210600016.pl | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/installer/data/mysql/db_revs/210600016.pl b/installer/data/mysql/db_revs/210600016.pl >index 8d66de86cb..6d03adc89d 100755 >--- a/installer/data/mysql/db_revs/210600016.pl >+++ b/installer/data/mysql/db_revs/210600016.pl >@@ -111,7 +111,7 @@ return { > # Now this is getting weird > # We are adding an extra news with the same code when the lang is not "default" (/"en") > >- $new_lang = "default" if $new_lang eq 'en'; # Assume that "en" is "default" >+# $new_lang = "default" if $new_lang eq 'en'; # Assume that "en" is "default" > > my $sth_update = $dbh->prepare(q| > UPDATE additional_contents >@@ -124,7 +124,7 @@ return { > $dbh->do(q| > INSERT INTO additional_contents(category, code, location, branchcode, title, content, lang, published_on, updated_on, expirationdate, number, borrowernumber) > VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) >- |, undef, $category, 'tmp_code', $location, $c->{branchcode}, $c->{title}, $c->{content}, 'default', $c->{published_on}, $c->{updated_on}, $c->{expirationdate}, $c->{number}, $c->{borrowernumber}); >+ |, undef, $category, 'tmp_code', $location, $c->{branchcode}, $c->{title}, '', 'default', $c->{published_on}, $c->{updated_on}, $c->{expirationdate}, $c->{number}, $c->{borrowernumber}); > > $parent_idnew = $dbh->last_insert_id(undef, undef, 'additional_contents', undef); > } >-- >2.34.1