Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-12716

3.4 -> 4.2 Upgrade does not migrate locales of translated documents

    Details

      Description

      Upgrade 3.4.14.11 which implements language translations for documents to 4.2.2.17.
      After the upgrading all documents with translations have the incorrect locale applied.

      For example, before the upgrade this node: workspace://SpacesStore/c0103349-1c66-420d-9a84-e5566c6edd19 has:

       {http://www.alfresco.org/model/system/1.0}locale = de 

      After the upgrade, it says: workspace://SpacesStore/c0103349-1c66-420d-9a84-e5566c6edd19

       {http://www.alfresco.org/model/system/1.0}locale = en_US 

      Steps To Reproduce

      Using Explorer v3.4.14.11 OOTB Installer

      1. Login to Explorer
      2. Create space
      3. Upload a single document
      4. Edit document properties - select action 'Make Multilingual'
      5. Expand 'Multilingual Content Info' section
      6. Select "English" (for pivot translation)
      7. Click button 'Add Translation with out Content' set title, set language 'German' (note name is automatically prepended from original with _de)
      8. Click button 'Add Translation' (with content), select file, set name (has to be unique from the file it is a translation of)
      9. Upgrade repository to 4.2.2.17 standard upgrade process

      Expected Behaviour

      • The document's value for sys:locale needs to be retained on upgrade to 4.x
      • {http://www.alfresco.org/model/system/1.0}locale is an alf_node_property for the mldocument
      • In 4.x the (new) alf_node.locale_id should = the alf_locale.id where the alf_locale.locale_str = value for sys:locale for that node
      • The mldocument sys:locale value (node browser) should be identical between 3.4 and the upgraded 4.x for the node

      Actual Behaviour

      • The document's locale needs to be retained on upgrade to 4.x
      • {http://www.alfresco.org/model/system/1.0}locale as an alf_node_property is retained for the mldocument
      • In 4.x the (new) alf_node.locale_id = the alf_locale.id where the alf_locale.locale_str = '.default'
      • The mldocument sys:locale value (node browser) is changed to the locale that is set as the '.default' value ex. all mldocuments are set to sys:locale='en_' if the '.default' = 'en_' and not the tranlsations original sys:locale value

      NOTE: this also affects the Manage Multilingual Content functionality in Explorer as well.
      When clicking on the Manage Multilingual Content button from any document (details), you do not see all the documents in the mlcontainer. I am assuming all the docs should be viewable in the list. The workaround outlined below seems to solve this as well.

      Additional Info

      Compared a ootb environment with upgraded environment. i.e. I installed fresh 4.2.x (no upgrade) and created multilingual docs.

      I compared the alf_node.locale_id (alf_node table) and the alf_locale table in the ootb fresh install. As I suspected, when creating the mldoc in this version it uses the alf_locale table. alf_node.locale_id is set to the translated locale for the mldocument.

      The upgrade/migration is not respecting the code now using the alf_locale table. The migration is setting all the locales to ".default". The migration is not populating the alf_locale table with the locales necessary to map the existing mldocuments to their corresponding locales.

      Code Trace:

      In the DBNodeService

      LocalizedPropertiesEntity.addLocalizedProperties – is causing the issue by replacing the nodes current locale {http://www.alfresco.org/model/system/1.0}locale=ru with the .default locale (changing the locale on login changes the .default)

      It uses the node.locale_id (alf_node table) (which is 2 in this case == .default) to compare to the alf_locale table and get the default locale.

      Looking at the same code (AbstractNodeDaoImpl.getNodeProperties) in 3.4.x I do not see a method e.g. LocalizedPropertiesEntity.addLocalizedProperties to add localized props to the node. Hence this is working in 3.4.x.

      Workaround

      Changing the alf_node.locale_id to the alf_node_properties for qname locale of the translation seems to fix the issue. In 3.4 the nodes use the alf_node_properties.prop_name to control the multilingual functions. The alf_locale table needs to be populated with all the locales from 3.4 mldocument nodes. The alf_node.locale_id need to be assigned the correct local_id to correspond to the locale in the alf_locale table.

      Work around steps
      1. Determine all the documents that are have mldocument aspect
      2. Confirm the locales for all the documents are available in the alf_locale table in 4.x version DB, if not add the missing ones
      3. Update the alf_node.locale_id (4.x DB) to match the expected locale (alf_node_properties.string_value where qname is 'locale') on the nodes in alf_node to be consistent what was in 3.4
      4 . confirm alf_node.local_id has been updated to match what was in the original 3.4 instances and associates to the correct id (locale) in alf_locale table

      NOTE The Indicator on the list page in the space is still showing incorrect locale. This is only true when the doc does not have content i.e it has the mlEmptyTranslation aspect. The pivot locale is used instead of the multilingual locale. This seems unnecessary but is enforced by an anonymous Inner class in BrowseBean.Java.
      e.g. public NodePropertyResolver resolverLang = new NodePropertyResolver()

        Attachments

          Issue Links

            Structure

              Activity

                People

                • Assignee:
                  closedbugs Closed Bugs (Inactive)
                  Reporter:
                  plungu Pavel Lungu (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  9 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 3 days, 4 hours
                    3d 4h

                      Structure Helper Panel