Skip to first unread message
ClaraC
Dec 9, 2020, 3:28:27 AM12/9/20
to AtoM Users
Hi everybody,
We have not made any changes that could affect this area and I have not found forum threads that discuss a similar error.
do you know why the actor-document relationships may not be displayed on the authority record screen?
We have not made any changes that could affect this area and I have not found forum threads that discuss a similar error.
Thanks,
Clara
Dan Gillean
Dec 10, 2020, 9:41:44 AM12/10/20
to ICA-AtoM Users
Hi Clara,
Can you tell us more about this issue?
Typically, the actor-description relationships do not display in the body of the authority record on the view page - instead, you will see them in the left context menu (AKA sidebar), listed as Creator of, Subject of, etc.
These relationships will show up in the edit page, so you can remove them or modify them from the authority record.
If there are relationships missing, then I would suggest you try some of AtoM's maintenance tasks first to see if it resolves the issue, such as:
Also, don't forget to clear your web browser cache or test in a private / incognito window, to ensure you're seeing the most recent version of the page and not an older cached copy.
Let us know if that helps! If not, please give us a bit more context about the issue you're encountering: your AtoM version, any changes you've made from our recommended installation instructions, what exactly led to the error, what you're seeing now vs what the expected result is, and any other information might help us understand the issue and recommend solutions.
Cheers,
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4bf6d2e4-787c-40c2-9a7f-aa1e25b47b82n%40googlegroups.com.
Message has been deleted
ClaraC
Jan 2, 2021, 5:21:19 AM1/2/21
to AtoM Users
Hi Dan, sorry but I was on vacation.
Relationships are not displayed on the Authority edit page.
We update to version 2.6.0 in September.
I attach a document with a copy of the screens
Any idea where the problem may be?
Thanks a lot.
Cheers,
Clara
El dia dijous, 10 de desembre de 2020 a les 15:41:44 UTC+1, Dan Gillean va escriure:
Dan Gillean
Jan 4, 2021, 10:15:12 AM1/4/21
to ICA-AtoM Users
Hi Clara,
I assume you have already tried my suggestions (clearing the cache, restarting PHP-FPM, rebuilding the nested set, reindexing)?
I noticed in your screenshot that it appears that the default languages are different - I wonder if there might be a translation display bug at play. Did you set the 2.6.0 upgrade to a different default culture than previously - or perhaps you left the default (English)? This might be something to check - you can find out the current default installation culture by looking in apps/qubit/config/settings.yml. See:
Remember, if you make any changes, don't forget to clear the application cache and restart PHP-FPM!
You could also try changing the display culture on the view page for your authority record, to see if the links display when viewed in the original culture. If they do, then this might be a display bug - I would expect these relationships to still be displayed even when viewed in a different culture.
Let me know what you find, and if needed, I can always file a bug report for us to investigate in a future release.
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a18f5097-34e8-48d5-9ce1-b4c6ca881d69n%40googlegroups.com.
ClaraC
Mar 1, 2021, 6:09:05 AM3/1/21
to AtoM Users
Hi Dan,
this is the problem, we changed default_culture: en to catalan according to the instructions (https://www.accesstomemory.org/es/docs/2.6/user-manual/administer/default-language/#default-language) and from that moment it stopped being displayed even changing the display culture on the view page for your authority record.
We have done:
php symfony cache:clear
php symfony propel:build-nested-set
sudo service memcached restart
sudo systemctl restart php7.2-fpm
So, it is better not to modify the default language? because in the manual are the option...
Cheers,
Clara
El dia dilluns, 4 de gener de 2021 a les 16:15:12 UTC+1, Dan Gillean va escriure:
Dan Gillean
Mar 1, 2021, 9:52:15 AM3/1/21
to ICA-AtoM Users
Hi Clara,
You should definitely re-index (php symfony search:populate) if you've changed the default culture. I'm hoping that might help! If it still doesn't work:
There is the possibility that there's a culture fallback issue with the relationships - culture fallback is used when translations are added for some fields but not others. In that case, when using the translated language as the viewing interface, any untranslated fields "fall back" to displaying the original source culture when no translation is available.
I'm wondering if perhaps there's an issue where your description and actor are created in different cultures - and possibly the relationship term used as well. One thing you could try doing is adding translations for any of those entities that are missing them in your chosen language. For example, if the relationship term was created in English, try navigating to the Actor relationships taxonomy, finding the relevant relationship term, flipping the user interface language to Catalan, and then editing the term to add a Catalan translation for it. You can do the same for the actor and the description.
Let us know how it goes!
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/32ec310b-6930-4927-b615-49fad69cbbe3n%40googlegroups.com.
ClaraC
Mar 3, 2021, 6:16:30 AM3/3/21
to AtoM Users
Hi Dan,
we re-index (php symfony search:populate) but it still doesn't work.
The description and creator were always created in Catalan. Later only in authorities was added a translation to Spanish.
Relationships that are not displayed correctly are Actor-document.
I have observed that in the taxonomy "Event Types" there are terms that we cannot edit (these are: Accumulation, Creation, Collection, Contribution, Custody, Publication). Only the buttom "add new" is available and I don't know if both errors can be related...
I can't find a solution.
Thaks a lot.
Cheers,
Clara
El dia dilluns, 1 de març de 2021 a les 15:52:15 UTC+1, Dan Gillean va escriure:
Dan Gillean
Mar 3, 2021, 10:03:05 AM3/3/21
to ICA-AtoM Users
Hi Clara,
Interesting. I think it is likely that these issues are related. If the original installation culture was changed, and/or Catalan translations were not present in AtoM for these terms when you first installed AtoM, then it's possible that this might occur. These terms are fixtures - meaning they are included at installation time as defaults, and are used in core AtoM functionality (linking descriptions to authorities), so they are locked to prevent their deletion or alteration in ways that would break core features in AtoM. However, this can pose a problem for translations for upgrading users. Our volunteer translation community does add new fixtures translations, but there's a known issue that prevents new translations from being applied to upgrading users who didn't previously have the translations, described here:
Fortunately, there is a manual workaround involving SQL, that you can try if you are willing to experiment a bit. I strongly recommend that you make a backup of your database before proceeding!
The instructions were for adding translations to terms in a different taxonomy, but the basic process is the same. First you will find the ID of the Event Types taxonomy. Then you use that to find the ID of the term in the Event Types taxonomy you want to translate. Finally, you use an INSERT statement to add the translation, and run a few maintenance tasks to apply the changes. See:
Note that in the first part of the tips included in the link, instructions are provided on how to access the MySQL command prompt, and point to the work-in-progress documentation on GitHub at the time. These docs are now complete, and you can read them here:
If you decide to try this, please let us know how it goes and if it resolves the issue!
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/9a409474-c6f1-422e-941a-f0d36fb96969n%40googlegroups.com.
ClaraC
Mar 9, 2021, 2:46:48 AM3/9/21
to AtoM Users
Dear Dan,
Thank you very much for your answer. I will check with whoever does the maintenance to see what they think about it.
Thanks again.
Cheers,
Clara
El dia dimecres, 3 de març de 2021 a les 16:03:05 UTC+1, Dan Gillean va escriure:
ClaraC
Mar 9, 2021, 8:37:53 AM3/9/21
to AtoM Users
Hi Dan,
We continue with the tests and checks because the problem persists.
The translations are fine and the actor-document relationship is created correctly but we cannot see the list of relationships in the authority record, so I am wondering if the problem is not in the relationships table.
What table is the one that links id_actor with id event type?
We have lost the functionality that is explained in the documentation, the section "Link an existing authority record to an archival description" > FROM THE AUTHORITY RECORD >point 7 https://www.accesstomemory.org/es/docs/2.6/user-manual/add-edit-content/authority-records/#link-authority-to-description because the list is not displayed.
Any idea what we can do?
Thanks again,
Clara
El dia dimarts, 9 de març de 2021 a les 8:46:48 UTC+1, ClaraC va escriure:
Dan Gillean
Mar 16, 2021, 9:57:55 AM3/16/21
to ICA-AtoM Users
Hi Clara,
mysql> describe event;
+----------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+-------------+------+-----+---------+-------+
| id | int | NO | PRI | NULL | |
| start_date | date | YES | | NULL | |
| start_time | time | YES | | NULL | |
| end_date | date | YES | | NULL | |
| end_time | time | YES | | NULL | |
| type_id | int | NO | MUL | NULL | |
| object_id | int | YES | MUL | NULL | |
| actor_id | int | YES | MUL | NULL | |
| source_culture | varchar(16) | NO | | NULL | |
+----------------+-------------+------+-----+---------+-------+
9 rows in set (0.01 sec)
I will ask our developers if they have further suggestions. Any further information you can provide about your installation will help. Based on what you've told me so far:
- Installation version: 2.6.0
- Original default installation culture: en
- Recent change to default installation culture: ca (Catalan)
Is that correct? Also, some other questions:
- Have you followed our recommended installation instructions for 2.6? (e.g. Ubuntu 18.04, PHP 7.2, MySQL 8.0, Elasticsearch 5.6, Nginx, etc). If no, what changes have you made?
- Does your site have a custom theme plugin? Or have you made any other modifications to the default Dominion theme?
In the meantime, I think the table you want to check is the event table:
mysql> describe event;
+----------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+-------------+------+-----+---------+-------+
| id | int | NO | PRI | NULL | |
| start_date | date | YES | | NULL | |
| start_time | time | YES | | NULL | |
| end_date | date | YES | | NULL | |
| end_time | time | YES | | NULL | |
| type_id | int | NO | MUL | NULL | |
| object_id | int | YES | MUL | NULL | |
| actor_id | int | YES | MUL | NULL | |
| source_culture | varchar(16) | NO | | NULL | |
+----------------+-------------+------+-----+---------+-------+
9 rows in set (0.01 sec)
There is also the event_i18n table. Basically, any string that is translatable in AtoM will typically live in a related i18n table. i18n is a developer's abbreviation for "internationalization" (because the word has 18 characters - hence i18n).
mysql> describe event_i18n;
+-------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------+------+-----+---------+-------+
| name | varchar(1024) | YES | | NULL | |
| description | text | YES | | NULL | |
| date | varchar(1024) | YES | | NULL | |
| id | int | NO | PRI | NULL | |
| culture | varchar(16) | NO | PRI | NULL | |
+-------------+---------------+------+-----+---------+-------+
5 rows in set (0.00 sec)
+-------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------+------+-----+---------+-------+
| name | varchar(1024) | YES | | NULL | |
| description | text | YES | | NULL | |
| date | varchar(1024) | YES | | NULL | |
| id | int | NO | PRI | NULL | |
| culture | varchar(16) | NO | PRI | NULL | |
+-------------+---------------+------+-----+---------+-------+
5 rows in set (0.00 sec)
I will see what suggestions our developers can offer.
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/8d837647-c1b8-43a0-a392-4777e4e2808an%40googlegroups.com.
ClaraC
Mar 16, 2021, 12:00:18 PM3/16/21
to AtoM Users
Thank you very much for your help Dan!
Yes, we followed your recommended installation instructions for 2.6 and this information is correct:
- Installation version: 2.6.0
- Original default installation culture: en
- Recent change to default installation culture: ca (Catalan)
- The site has theme plugin “arDominionPlugin” without any modification.
I tell you about our current situation:
Today we have re-established the default culture of our installation to English again. And if we put it back in English, the list appears in the Relationships Area.
After checking the following tables:
- information_object and information_object_i18n
- actor and actor_i18n
- relation and relation_i18n
- taxonomy and taxonomy_i18n
- term and term_i18n
- event and event_i18n
... we have detected the following errors that we must correct:
- translations that have been created incorrectly (I don't know how).
- wrong source-culture in English or Spanish of some records (I guess it is due to not changing the language before logging in).
About your suggestion related with table event we checked the event table and the event_i18n table with this SQL query too:
SELECT event_i18n.*, event.*
FROM event_i18n LEFT JOIN event
ON (event.id = event_i18n.id)
WHERE event.source_culture="es/ca/en"
... and the results obtained were:
- no results with source_culture in English
- 78 results with source_culture in Spanish
- 826 results with source_culture in Catalan, but with wrong translation in English.
I deduce that if we purge the
wrong translations and source_culture of the related records, they will also
disappear from the “events” and “event_i18n” tables.
Do you know if we can remove translations and
modify the source_culture without
losing information?
I have seen this discussion on the forum but I don't know if there is anything else on these topics: https://groups.google.com/g/ica-atom-users/c/XxMu3y5w2wU/m/ZcaWsIaGyFkJ
Our intention is to have the portal in Catalan to avoid forgetting the language change before identifying yourself (errors such as those that have already occurred) but we do not want to lose the functionality of the Relationships Area, so we appreciate any suggestions you can give us .
PS: I am attaching the excel with the results obtained for the Event-Type taxonomy where you can see that the translations to Accumulation, Creation, Collection, Contribution, Custody, Publication were created in Catalan and Spanish.
El dia dimarts, 16 de març de 2021 a les 14:57:55 UTC+1, Dan Gillean va escriure:
ClaraC
Apr 6, 2021, 7:38:48 AM4/6/21
to AtoM Users
Hola Dan y resto de usuarios del grupo,
les informo que tras un proceso de depuración de nuestra base de datos hemos conseguido que vuelva a estar visible y operativa el Área de Relaciones de los registros de autoridad con el idioma por defecto del portal modificado a catalán.
El procedimiento que seguimos fue:
1. Volvimos a dejar el portal con default_language = EN.
2. Eliminamos traducciones incorrectas y modificamos el atributo "source_culture" de todos los registros que tenían el valor "EN" y "ES" en las siguientes tablas:
information_object + information_object_i18n
actor + actor_i18n
event + event_i18n
3. Aprovechamos para depurar todo lo que vimos incorrecto.
4. Cambiamos el idioma a catalán y funcionó.
Como saben nuestra instalación de AtoM se realizó en un primer momento con el idioma por defecto en Inglés pero luego lo hemos modificado a catalán ya que tanto el portal como las descripciones las estamos creando en dicho idioma y se estaban produciendo errores inesperados.
Hemos modificado "source_culture" sólo de las tablas que nos recomendó Dan y que pensamos que tenían relación con "Relationship area" pero aún existen tablas en la base de datos que mantienen el atributo "source_culture" con el valor "EN" (aunque actualmente tengamos default_language = CA) y alguna taxonomía con varios valores: "EN" y "CA".
Queremos evitar tener que volver a depurar la base de datos y sobre todo futuros errores en relaciones, indexaciones y actualizaciones. Así que sólo una última pregunta:
¿Se puede modificar "source_culture" de todas las tablas de la base de datos para que el valor sea "CA" o esta acción sería incorrecta?
Muchas gracias por sus sugerencias.
Saludos,
Clara
El dia dimarts, 16 de març de 2021 a les 17:10:11 UTC+1, ClaraC va escriure:
Dan Gillean
Apr 6, 2021, 12:01:56 PM4/6/21
to ICA-AtoM Users
Hi Clara,
I do not recommend bulk changing all "source_culture" values in every AtoM table to ca - if you do, I suspect this will create some unexpected errors!
There are some records in the database that expect to have an "en" source culture - for example, some of the default terms included in taxonomies during installation; some of the settings, some of the menus and static pages, the notes and note types, etc...
For now, you may want to leave things as they are and only resolve issues if / when they appear.
If you want to continue to update tables, then you may want to create a separate new and empty installation (with a default culture of CA), so you can look over the tables and see what is included in a default installation with "en" as the source culture. You can then compare this to your installation, to make sure you don't modify anything that appears as en in a default clean installation.
Also, before you change source_culture values, you should check to see if a CA culture row exists in the related _i18n table - otherwise your changes may have unexpected results.
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/44f01b27-56b5-4e1d-a569-d8dfc099db20n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages