Vagrant installation: Dates can not be stored for archival descriptions

89 views
Skip to first unread message

Markus Hemprich

unread,
Oct 25, 2021, 1:42:06 PM10/25/21
to AtoM Users
Hello AtoM users,

after installing AtoM on vagrant, I have tried to use some archival descriptions. However, I have not been able to enter any dates in the Identity Area of the archival description. Whenever I store the new entry, the input seems to be lost and will not be shown anymore.

If I import an item description via CSV, the dates will be shown. As soon as I start changing some part of the dates, the complete dates information is erased after saving.

Is there a know issue in vagrant? Or in AtoM 2.6.4?

Or do I have to configure something to use dates?

Markus

Markus Hemprich

unread,
Oct 25, 2021, 1:57:11 PM10/25/21
to AtoM Users
Correction: my vagrant box is not v2.6.4 but v2.7.0.3

It seems that the same problem was described for v2.6 in the following post: https://groups.google.com/g/ica-atom-users/c/x2rA7s9_WJA/m/40xcheJfAQAJ
The recommendation in this post was to instlall v2.7

Dan Gillean

unread,
Oct 26, 2021, 10:06:46 AM10/26/21
to ICA-AtoM Users
Hi Markus, 

I suspect that updating the Vagrant environment should resolve these issues. When installed, the Vagrant environment will set up AtoM based on how it was when the development environment was first created - but a number of configuration changes, features, and bug fixes have been added to our development branch since we first created that environment. I would recommend you try the following steps to upgrade your environment. 

First, if you have made any local code changes that you wish to preserve, I would recommend that you try using git stash to stash them away, so we can pull in the attest changes. Be aware that if you have made local code changes, there could be conflicts (depending on the changes) after updating and trying to unstash them that you will have to resolve. 

Additionally, if you have any data that you want to keep in your development environment, you should make a backup. See: 
In the Vagrant box, if you want to create a backup called backup.sql to the directory where you installed the Vagrant box on your host computer, you can use: 
  • mysqldump -u atom-user -pATOMPASSWORD atom > /vagrant/backup.sql
Now we'll go through some of the steps usually used during Upgrades. Just to be sure, let's run the purge command - this will purge all data from the database, so make sure you have backed up any data you want to keep! We'll use the --demo option - if you have backed up data, it will be overwritten with your existing data and user accounts when we load it back in later so it won't matter. From AtoM's root directory inside the vagrant box (/home/vagrant/atom), which is a symlink for /usr/share/nginx/atom), run: 
  • php symfony tools:purge --demo
Let's make sure we are reset to the latest HEAD in git, then pull in the latest code changes now: 
  • git reset --hard HEAD
  • git pull --rebase
We will now drop and recreate the database: 
  • mysql -u atom-user -pATOMPASSWORD -e 'DROP DATABASE atom; CREATE DATABASE atom CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;'
Now we can load back in any backed up data if you have it:
  • mysqldump -u atom-user -pATOMPASSWORD atom < /vagrant/backup.sql
Run the upgrade task: 
  • php symfony tools:upgrade-sql -B
Clear the application cache and restart services: 
  • php symfony cc
  • sudo systemctl restart php7.4-fpm
  • sudo systemctl restart memcached
  • sudo systemctl reload nginx
  • sudo systemctl reset-failed atom-worker
  • sudo systemctl restart atom-worker
Re-index the site: 
  • php symfony search:populate
Hopefully this should resolve the issue you've encountered! Let us know how it goes. 

Also, if you didn't have any data to load, try the following credentials to log in as an administrator: 
And if those don't work, you can create a new administrator account via the command line, with: 
You can now also unstash any local code customizations. 

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/1283fb56-5cc0-4bc2-af82-8e56978cb505n%40googlegroups.com.

Markus Hemprich

unread,
Oct 26, 2021, 4:45:23 PM10/26/21
to AtoM Users
Hello Dan,

thank you very much for the great support. Atlhough there were many steps to take, I was surprised that it worked out well and did not take a lot of time.
The only thing, which I had to change, was the database restore. After I change the command to the following line, it worked:
mysql  -uUSER -pPASSWORD -r atom < /vagrant/backup.sql

Now, the system is running again and my data seems to be back. 

The bug with the date is gone and I can enter dates now! This looks great!

There are 2 things to mention:
1) I was surprised that the "Application Version" (in the admin settings) is now: 2.6.0 - 192   . Is this o.k.? I expected 2.7.0.x
2) The generation of finding aids tops with and error, e.g. it shows "Status: error" in the side bar. Is this under construction?

Thanks again,

Markus

Dan Gillean

unread,
Oct 27, 2021, 9:22:44 AM10/27/21
to ICA-AtoM Users
Hi Markus, 

Regarding the application version, I recently posted about this in another thread - I will copy my response here: 

The Vagrant and Docker boxes are development environments that pull from the QA branch of our code repository. We do not formally bump the software version until a public release is created, so what you are seeing is not unexpected. The second number in Admin > Settings > Global > Version is the database schema version - every time a new or updated feature requires a change to the database, we add a schema migration so that the underlying data model will be updated correspondingly when users upgrade. 

Currently I believe that the development branch should be at schema v192 - so the version in settings should say 2.6.0 - v192 right now. For reference, the 2.6.4 stable public release was 2.6.4 - v184. 

Regarding the finding aid issue: 

First, I would recommend going to Manage > Jobs, finding the relevant finding aid generation job, and seeing if there are any more details about the error listed there. If there's nothing, you can also check the Nginx error logs with the following command: 
If the message says something like, "No Gearman worker available that can handle the job," then it means that the job scheduler needs to be restarted. See this thread for further suggestions and details:
On the other hand, the issue could be with something that is in the record itself - for example, if you have copied and pasted content into AtoM's edit forms, it's possible you have inadvertently included a non-UTF-8 character that might break the conversion process. We have some suggestions on this in the documentation here: 
If it doesn't seem like that is the issue either, please share the error message you find in the error log, and hopefully we can offer further suggestions. 

Cheers, 

Dan Gillean, MAS, MLIS

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ca868ae0-c97d-47a7-ba7c-3074d13c6ecbn%40googlegroups.com.

Markus Hemprich

unread,
Oct 27, 2021, 2:37:17 PM10/27/21
to AtoM Users
Hi Dan,

thanks for the further hints. I am happy to learn that I seem to be on the latest (2.6.0. v192) version :-)

Regarding the finding aid generation, I checked the logs with "sudo tail ..." and found an error about the Gerrman worker. After restarting the worker with "sudo systemctl restart atom-worker", the finding aid generation worked fine.

Thanks again!

Markus
Reply all
Reply to author
Forward
0 new messages