[Koha-bugs] [Bug 31383] Additional contents: We need a parent and child table

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31383

Jonathan Druart <jonathan.druart+koha at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #153666|0                           |1
        is obsolete|                            |
 Attachment #153667|0                           |1
        is obsolete|                            |
 Attachment #153668|0                           |1
        is obsolete|                            |
 Attachment #153669|0                           |1
        is obsolete|                            |
 Attachment #153670|0                           |1
        is obsolete|                            |
 Attachment #153671|0                           |1
        is obsolete|                            |
 Attachment #153672|0                           |1
        is obsolete|                            |
 Attachment #153673|0                           |1
        is obsolete|                            |
 Attachment #153674|0                           |1
        is obsolete|                            |
 Attachment #153675|0                           |1
        is obsolete|                            |
 Attachment #153676|0                           |1
        is obsolete|                            |

--- Comment #72 from Jonathan Druart <jonathan.druart+koha at gmail.com> ---
Created attachment 156048
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=156048&action=edit
Bug 31383: Create a parent-child DB relation for additional content

In the design of additional contents the idea of a parent-child relation is
implicitly present. You have a default page and translations.
But we do this in one table coming from the old news items.

Several reports show that we would be better off creating a parent table
listing the main news items, CMS pages or HTML content. And a child table
containing the title, content and lang.

Note that this first step is a prelimenary step to clean this area and make it
more robust and extensible. More enhancements to come.

What is this patchset doing?
* DB changes
- Rename additional_contents.idnew with id
- Create a new table additional_contents_localizations(id,
additional_content_id, title, content, lang) that will contain the translated
contents
- Move the content to this new table
- Remove title, content and lang columns from additional_contents
- Replace the notice templates that are using ''<news>" (should only be
ISSUESLIP) and remove support for this syntax. Also add a warning in case other
occurrences of uses of the old syntax exist.

* CRUD
- We add a new Koha::AdditionalContentsLocalization[s] couple, and move some
logic from Koha::AdditionalContent[s] to there. Note that, to prevent too much
drastic changes in notice templates, and to make them easy to use, the
different attributes of the content object is accessible from the translated
content object (ie. Koha::AdditionalContentsLocatlization->library is available
and return $self->additional_content->library). I think it's an elegant way to
keep things simple.
- No changes expected for "NewsLog" logging
- Little behaviour changes for pages, see tools/page.pl changes. We are now
passing the id of the content, and the desired language, instead of the mix of
"page_id" or code and lang. Note that here we certainly need to rename
"language" query param to not change the full interface language.

Test plan:
0. Preparation steps, use master
  a. Create notice templates that are using "<< additional_contents.code >>".
This won't be replaced, but we want the update process to alert us.
  b. Create several news, additional contents, pages. Some with translated
contents, some without.
  c. Make sure ISSUESLIP has the "<news>" section. If you are using the sample
data there is nothing to do here
  d. Turn on NewsLogs
1. Apply the patches, restart_all, updatedatabase
=> Confirm that the new table is created and filled with the contents you had
prior to the update
=> Confirm that additional_contents_localizations.updated_on has been kept to
the previous values
=> Confirm that ISSUESLIP has been replaced properly
=> Confirm that you get a warning about the additional_contents
2. Create, update, delete news, html customs, pages
=> Confirm that the additional_contents_localizations.updated_on is only
adjusted when required
=> Confirm that the logs are correctly created when NewsLogs is on
3. Check some items out, generate a slip
=> Confirm that the news are displayed at the bottom of the slip, and that the
publication date is correctly formatted
4. Have several HTML customizations (like OpacNav, opacheader), in translated
in different languages
=> Confirm that the default values is displayed when you are using the
interface in a language without translation
=> Confirm that the translated version is picked when it exists

Notes for QA:
* I am not sure we really need the alert during the update DB process about the
additional_contents leftover. We should not have them outside of ISSUESLIP.
Shouldn't it hurt?
* There is something ugly in sample_news.yml, the id is hardcoded. But how do
we prevent that and keep translatability?

Sponsored-by: Rijksmuseum, Netherlands

Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>

-- 
You are receiving this mail because:
You are watching all bug changes.