Disappearing data following upgrade to AtoM 2.7.1

95 views
Skip to first unread message

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

unread,
Apr 26, 2023, 4:55:32 AM4/26/23
to AtoM Users
Good morning,

We updated out version of AtoM yesterday to 2.7.1 and have come across an issue with data disappearing.  We have found that dates in particular (but sometimes other information as well) disappear if you open and edit an archival description, or just open it for editing and save it without changes.  It seems the only way to retain the dates is to manually add them back in and then not do any further edits to that record of any kind.

Jim Adamson, our IT support for AtoM, has run the following commands, but unfortunately this has not solved the issue.

cd /usr/share/nginx/atom php symfony propel:build-nested-set php symfony cc systemctl restart php7.4-fpm systemctl restart memcached php symfony search:populate

Has anyone else come across this issue and found a solution for it?

Thanks,

Sally


Dan Gillean

unread,
Apr 26, 2023, 9:41:47 AM4/26/23
to ica-ato...@googlegroups.com
Hi Sally, 

Thank you for this report. Any further information you can provide? For example: 
  • Am I recalling correctly from a previous post by Jim that you are using the new Bootstrap 5 templates?
  • Can you please give me the full AtoM version number shown in Admin > Settings?
  • Any other information to reproduce this issue? For example, were the edited descriptions all created via imports, or manually via the user interface? 
  • Does your installation follow all the recommended dependencies (i.e. Ubuntu 20.04, PHP7.4, MySQL8, Nginx, Elasticsearch 5.6, etc)? If no, what changes have been made?
  • Does your system include any local code customizations, and/or a custom theme?
In the meantime, I will pass this information on to the maintainers for their testing and review. Hopefully with a bit more information we can reproduce this and get it sorted! 

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/b166cbe4-f4fb-4d6e-9b21-edbd03eebba9n%40googlegroups.com.

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

unread,
Apr 26, 2023, 9:54:53 AM4/26/23
to AtoM Users
Hi Dan,

To answer some of your questions,

  • The version number is 2.7.1 - 192
  • The error first appeared after I had manually added new entries. However I have now tested it on manual and csv imported entries and it happens on both.  Even if I only open a file for editing and then save without changes the date disappears. However I can't replicate this error in our test version of 2.7.1-192.
I have asked Jim if he could answer the other more technical questions so I will add an update (or Jim will) asap.

Thanks for your help,

Sally

Jim Adamson

unread,
Apr 26, 2023, 10:27:11 AM4/26/23
to ica-ato...@googlegroups.com
Hi Dan,

To answer your questions:
  • No, we're still using a slightly modified version of the old BS2 arDominion theme for now.
  • Yes, our installation follows the standard dependencies for 2.7 - Ubuntu 20.04, mysql-server 8.0.32, elasticsearch 5.6.16, php 7.4, nginx 1.18.0. These are all managed by Puppet, so will be consistent between test & production servers.
  • Yes, there are local customisations, but they're fairly limited. We're now managing our customisations in GitHub, rather than using a Puppet class to overwrite the default files. Basically, we now have a fork of artefactual/atom - https://github.com/Jimadine/atom-york and we're on stable/2.7. Our custom theme is embedded within our fork as a git submodule, as we already had a separate repo for the theme. There are very few differences with the latest BS2 arDominion theme; I sync'd up quite recently leaving only our required customisations to things like colours in place.
I realise that having additional customisations make this difficult to support, and I will double check what we've changed just in case there's something that could account for this. As Sally has said, we've not been able to replicate this on our test server, which should be the same, bar the data which is a few weeks older than the production server.

Thanks, Jim



--
Jim Adamson
Systems Administrator/Developer
Facilities Management Systems
IT Services
LFA/023 | Harry Fairhurst building | University of York | Heslington | York | YO10 5DD

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

unread,
Apr 26, 2023, 10:32:28 AM4/26/23
to AtoM Users
Hi both,

I just wanted to add that I've realised if you open an entry in edit mode and click 'save' to close, the date disappears, but if you open it in edit mode and click cancel to close, then ALL data disappears.  A colleague mentioned this and I've just tested it with a manual entry.  

I don't know if this makes a difference to the investigation of the issue but I thought I ought to mention it. Again these problems to not happen in the test version.

Best,

Sally

Dan Gillean

unread,
Apr 26, 2023, 11:30:28 AM4/26/23
to ica-ato...@googlegroups.com
Thank you so much for this additional information, Sally and Jim. We'll see if we can reproduce this locally. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

Brandon Uhlman

unread,
Apr 26, 2023, 1:16:54 PM4/26/23
to AtoM Users
This sounds vaguely like an issue we identified in May 2021, and which was fixed for AtoM 2.7.0. Short version: AtoM 2.7.0 introduced CSRF protection (against forging form submissions). Even though the archival description editing inteface looks like a single large form, behind the scenes it's actually multiple sub-forms (each date row, in particular, is it's own subform), and there was a bug in how the subforms were getting created that caused them to be treated like they were forged requests and the data was dropped.

Maybe it's worth a check to make sure your local fork includes the necessary changes from the pull requests in the ticket? (I think the later pull request, PR#1460, backs out the earlier pull request and applies the required change a different way.)

Brandon

Jim Adamson

unread,
Apr 27, 2023, 4:48:20 AM4/27/23
to ica-ato...@googlegroups.com
Hi Brandon,

Thanks for the suggestion. I have checked and it looks like we do have the code changes made in PR#1460.

Thanks, Jim

--
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.

Jim Adamson

unread,
Apr 27, 2023, 8:05:44 AM4/27/23
to ica-ato...@googlegroups.com
Hi Dan,

We've done some further testing, and what we've found is that using a "clean" Chrome browser does seem to resolve the problem. It was initially observed that the problem wasn't apparent in Chrome Incognito mode nor in Firefox (which is seldom used). I then advised to clear the Chrome site data for the specific site (padlock -> Site settings -> Clear data button), but that seemed not to be enough; an all sites browsing data purge was required (cookies, cached images & files, passwords & other sign-in data, & autofill form data were purged - probably overkill but that did resolve it).

It's a bit concerning that this is required, but we'll share the above fix with colleagues and keep an eye on things. Thanks for your support!

Thanks, Jim

Dan Gillean

unread,
Apr 27, 2023, 8:26:59 AM4/27/23
to ica-ato...@googlegroups.com
Hi Jim, 

Interesting... thank you so much for the update - and for sharing your thoughts as well, Brandon!

I'll be passing on both of these updates to the Maintainers - this is concerning enough that we will definitely be doing our own investigation. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

Reply all
Reply to author
Forward
0 new messages