Description Change Logging

[sally-an...@york.ac.uk]

Good morning. I messaged the forum back in December about how to find out which AtoM users had created which archival descriptions. As a result of the helpful advice I received we have enabled 'description change logging'.  However now we want to use it, it doesn't appear to be working properly.  The option to filter by username is there but when you select a username and hit 'search', it seems to reset and just show all the recent descriptions.  As in, they're not filtered by username.

I've had another look at the documentation but I can't see what I've done wrong. Has anyone else had this problem?

Best,

Sally-Anne

[Dan Gillean]

Hi Sally-Anne, 

I've just done a quick test in our development environment, and it worked as expected for me. Here's what I tried: 

1. Log in as an administrator and confirm that Description change logging is enabled in Admin > Settings
2. Log out, and log in as an Editor user
3. Update two existing descriptions, and create one new description as the Editor user
4. Log out, and log back in as the Administrator
5. Navigate to the Description Updates page
6. Configure the search filters, filtering by the Editor user

In my case, everything seemed to work as expected. Are you doing anything different that I should try?

Note that if you change any of the search filter parameters (such as switching from Date of creation to Date of revision), you need to manually reapply the user filter before submitting - AtoM will display the name of the current user it is filtering the results on below the filter, but it actually clears the filter field in the process, so resubmitting the query without reapplying the specific username will return results for all users. 

Remember as well that the filter will not apply retroactively before the Description change log setting was enabled - so if you turned it on in December of 2021, then the earliest per-user results you'll see will be that month. Additionally, by default the date range filter is set to 30 days - be sure to expand this if needed before submitting your search. 

When you submit your search, is AtoM displaying the chosen user below the filter afterwards, like so?

Once I hear back from you, I will do a few more tests and see if I can recreate the issue you describe. If there's no obvious difference in our workflows, please tell me more about your installation environment, such as the full version number of AtoM you're using (shown in Admin > Settings > Global), whether you're following the recommended installation instructions or if you've made any changes (and what changes you've made), whether you have any custom local development in place (either code changes or custom plugins, including a custom theme plugin), and anything else you think might help me better understand the issue. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

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/5fbbb468-25a0-4940-978b-d70e107ed641n%40googlegroups.com.

[sally-an...@york.ac.uk]

Hi Dan,

Thank you so much for this. I've just tried the steps you set out and unfortunately the problem is still happening (and our previous month's data has disappeared).  No matter which username you put in, as soon as you hit search it appears to just reset and the same results always appear.  It does not say 'currently displaying: Editor' or anything similar.

I have emailed Jim Adamson to ask about our installation and changes.  We are running AtoM 2.6 now. I'll let you know more as soon as I hear back.

Best,

Sally

[sally-an...@york.ac.uk]

Hi Dan,

I've heard back from Jim now, who says the following,

There are a number of customisations to php files, and we use a custom theme (https://github.com/digital-york/Borthwick-Catalogue-CSS-theme). However, my feeling is that this problem is unrelated to any of the customisations, because the modifications are only to files that shouldn't have effect on what's displayed in the body of the Description Updates page. I could be wrong though.

I will list the customised files anyway:

/usr/share/nginx/atom/apps/qubit/templates/_header.php
/usr/share/nginx/atom/apps/qubit/templates/_footer.php
/usr/share/nginx/atom/apps/qubit/modules/search/templates/_box.php
/usr/share/nginx/atom/apps/qubit/modules/default/templates/_popular.php
/usr/share/nginx/atom/apps/qubit/modules/default/actions/popularComponent.class.php
/usr/share/nginx/atom/apps/qubit/modules/menu/templates/_quickLinksMenu.php
/usr/share/nginx/atom/apps/qubit/modules/menu/templates/_userMenu.php
/usr/share/nginx/atom/lib/QubitInformationObjectXmlCache.class.php

If any of the above files stand out as likely to be involved, I'd be happy to diff them with the official ones to see if our customisations are the cause. Also, I turned off the stylesheet in my browser and the problem was still apparent, so I'd presume this means the custom theme is not the cause.

In terms of the installation process, it broadly adheres to the official installation instructions, though all of the work is done by Puppet.

Thanks,

Sally

[Jim Adamson]

Hi Dan, Sally,

To add that at York we are running AtoM 2.6.4 - 184 (tarball).

One thing that we can try in our test environment is to swap-in the standard copies of the php files listed below to rule out a local cause. Though there haven't been any recent description updates made in our test environment, when picking a user from the dropdown and clicking the 'Search' button, the UI indication that a particular user is being filtered on is absent, as per our production environment.

Thanks, Jim

[Dan Gillean]

Hi Jim, 

You're right, at first glance I don't see anything in those particular files that, if modified, should directly affect the behavior of this filter on the Description updates page. Despite this, I'm waiting on a developer to take a look at this thread and see if they can offer further suggestions on next steps. I haven't found any particular bug tickets that seem related to this, but it's possible something was fixed in our qa/2.x branch, so I will try to reproduce the issue in a stable/2.6.x test environment instead, to see if it's something particular to 2.6.x releases that might already be resolved in the upcoming 2.7 release. 

Is there anything related in the webserver logs? Or, does Debug mode reveal any further useful information? Are there any MySQL logs that might have relevant info? Can you confirm that the SQLmodes being used match those recommended in our installation docs? See: 

• https://www.accesstomemory.org/docs/latest/admin-manual/installation/linux/ubuntu-bionic/#mysql
  
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/common-atom-queries/#check-server-sql-modes
  

When I've had a chance to do a bit more testing, as well as consult with a developer, I'll let you know what I've learned. In the meantime, if there is any other information that you think would help us to reproduce this or narrow down the possible causes, feel free to add it. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/413f6017-88c9-438b-9460-7b6960d4af4fn%40googlegroups.com.

[Jim Adamson]

Hi Dan,

I restored the standard copies of those PHP files, just to be sure, and the result was the same.

I enabled Debug mode in our test environment, but couldn't see any signs of errors. The MySQL error.log contains no new lines after following the steps to reproduce. We're running MySQL 8.0.23 from the MySQL APT repository.

Yes, we have the following lines in our MySQL server configuration file:

sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

optimizer_switch = 'block_nested_loop=off'

To verify these lines are in effect, the recommended SQL gives me:

mysql> SELECT @@sql_mode, @@GLOBAL.SQL_MODE;
+---------------------------------------------------+---------------------------------------------------+
| @@sql_mode                                        | @@GLOBAL.SQL_MODE                                 |
+---------------------------------------------------+---------------------------------------------------+
| ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+---------------------------------------------------+---------------------------------------------------+
1 row in set (0.00 sec)

I've also been able to reproduce this in a Vagrant box.

Clicking the Search button after selecting the user to filter on generates the following lines in Nginx's access.log. It might be worth checking against a working AtoM instance to see if there's anything strikingly different about the lines?

144.32.225.29 - - [16/Feb/2022:12:40:31 +0000] "GET /index.php/search/descriptionUpdates?showForm=1&className=QubitInformationObject&dateOf=CREATED_AT&publicationStatus=all&user=%2Findex.php%2F8c2a-ezpa-69zx&startDate=2022-01-16&endDate=2022-02-16 HTTP/2.0" 200 4866 "https://atomtest.york.ac.uk/index.php/search/descriptionUpdates?showAdvanced=1&topLod=0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36"
144.32.225.29 - - [16/Feb/2022:12:40:31 +0000] "POST /index.php/user/clipboardStatus HTTP/2.0" 200 66 "https://atomtest.york.ac.uk/index.php/search/descriptionUpdates?showForm=1&className=QubitInformationObject&dateOf=CREATED_AT&publicationStatus=all&user=%2Findex.php%2F8c2a-ezpa-69zx&startDate=2022-01-16&endDate=2022-02-16" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36"

It seems odd that there's a POST to /index.php/user/clipboardStatus immediately following the form submission (the GET)... but I guess it could be a red herring.

The only other thing I noted was that the value for the user in the GET submission is a concatenation of /index.php/ and a string of characters which presumably represents the user:

If I remove /index.php/ from that URL param, and submit the form via my web browser address bar, I do actually see a line that's prefixed "Currently displaying:" followed by the email address of the user, in the middle of the page, just below the User dropdown. So maybe that's where the problem lies? It seems that in the course of writing this email I've hit upon a possible cause :-)

Many thanks for your ongoing support with this, Dan.

Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BMxk-0QCAR2rj220mBxkZPqGOp32cCKC2vN9J%3DXSaAvg%40mail.gmail.com.

--

Jim Adamson

Systems Administrator/Developer
Facilities Management Systems
IT Services

LFA/023 | Harry Fairhurst building | University of York | Heslington | York | YO10 5DD

+44 (0)1904 323859

Email disclaimer: https://www.york.ac.uk/docs/disclaimer/email.htm

[Dan Gillean]

Hi Jim, 

Interesting! Have you modified AtoM so that the index.php is not included in most URIs? This is typically done by setting the no_script_name parameter to true in the apps/qubit/config/settings.yml configuration file, then clearing all caches and restarting PHP-FPM. I'm wondering if doing so might have unexpected effects while in the Description Updates module with the audit log enabled. 

I will check in with our team and see if this additional information helps us to identify the underlying cause. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAEz_m%3DR23J9HwpyPFObiS_Ae1AOjUGwXPHZ7tOF8QT4sWqQJZw%40mail.gmail.com.

[Jim Adamson]

Hi Dan,

I've checked settings.yml and no_script_name was set to false (the default). I set it to true in our test environment and that does seem to have resolved the issue. Are there likely to be any unforeseen side-effects on other pages as a result of setting no_script_name to true?

I tracked down the relevant line in the code here. Not sure why it needs to echo the URL to the value attribute.

Thanks, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B0%2BYbHjOnZsP2Qja6ANMu8v%2B9rKKRmSkga8OE2ad5t%3DQ%40mail.gmail.com.

[Dan Gillean]

Hi Jim, 

Strange! I've not heard of any known issues setting that parameter to true, so hopefully that's the end of that. 

Random thought: Is your Base URL properly configured in your settings' Site Info? The base URL should typically not end in a slash, nor should it include index.php. I'm not sure if this might have any relevance here, but if that particular bit of code is echoing a URL, then it may be using the Base URL setting. I'll try to see if our developers have any further thoughts. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAEz_m%3DSE5RaRNAHJXmYqzmDY7gAeOgfLe8_7uzijy0UmG8_c1g%40mail.gmail.com.

[Jim Adamson]

Hi Dan,

I've checked and the site base URL is http://borthcat.york.ac.uk, so I don't think that's it.

I might have a look and see if I can reproduce this in a completely vanilla environment, i.e. manual installation with no customisations, just to be sure.

Thanks, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZL%2Bkbn0qg1Ys5ja9tjk3JfFe7sWRAmAKB%3DX7Y-S1DB%3DFA%40mail.gmail.com.

[Jim Adamson]

Hi Dan,

I've managed to reproduce this in a vanilla Vagrant environment I built from following the Ubuntu 18 instructions with all of the default config:

Just as an aside, the line in the instructions that adds the MySQL APT repository list needs to be updated from:

wget https://dev.mysql.com/get/mysql-apt-config_0.8.15-1_all.deb

to

wget https://dev.mysql.com/get/mysql-apt-config_0.8.22-1_all.deb

With the 0.8.15 version, a defunct key is installed, causing an error after 'apt updating':

W: GPG error: http://repo.mysql.com/apt/ubuntu bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29
E: The repository 'http://repo.mysql.com/apt/ubuntu bionic InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

This is also fixable by running:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 467B942D3A79BD29

Thanks, Jim

[Dan Gillean]

Hi Jim, 

Thanks so much for this further sleuthing. I originally performed my tests on our qa/2.x branch - meaning either I failed to properly reproduce the issue, or else the bug has been resolved in the upcoming release. I'll do some more testing on 2.6 and the development branch and see if we need to file a ticket here. 

Regarding the docs - thanks for the reminder! Another user mentioned this to me recently, and while I had already made the change, it hadn't been pushed to the website yet. I've done that now: 

• https://www.accesstomemory.org/docs/2.6/admin-manual/installation/linux/ubuntu-bionic/#mysql
  

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAEz_m%3DREWL7F%3DGihYtZ%2Bg3zrDR7gf_J3a226NpwqwrpsEUx8wg%40mail.gmail.com.