Error when trying to unlink physical storage

[York Explore Libraries and Archives]

Hello, we are using AtoM 2.6 but have a problem with unlinking physical storage. We are in the process of moving some archive boxes from one shelf to another, so we need to unlink the current container and relink to a new container. We are trying to do this from the archival description by clicking  on More/Link physical storage. However, when we try to delete the currently linked container the change cannot be saved and it remains linked to this container. Has anyone else had this problem? 

Thanks, Julie-Ann

[Dan Gillean]

Hi Julie-Ann, 

The process you describe matches what our documentation recommends for removing container associations from descriptions. However, I just did a quick test in our public demo site and was able to remove a container association from a description there. Can you provide me with a bit more information, so we can offer further suggestions and/or determine if this is a bug in AtoM?

First, what exactly happens when you click the save button - do you get an error message, or does the page reload to the description, but without removing the container link?

Additionally, what is the full AtoM version number listed in Admin > Settings at the top of the page?

If I've found the right public-facing catalogue for your institution, I noticed that you have a custom theme from Max Communications. Is your site also hosted by them? If yes, then I would recommend contacting them to investigate further. Most recommendations I have for you involve access to the back end of your application (i.e. the command-line), so either a local system administrator (if you are self-hosting) or someone from Max (if they are hosting) can use the suggestions below as a starting point. 

It's possible that some element of your custom theme is interfering with the elements used to remove the container association before the form is submitted (such as the JavaScript used to animate the container being removed when you click the X in the edit page). We do have some recommendations for things to check in custom themes when upgrading in our documentation (here), but it also depends on the theme itself and how it was developed, what it changes, etc. It could also be as simple as the theme CSS needing to be recompiled.

In general, when there are errors or unexpected behaviors, one of the first things we recommend is checking the webserver error logs to see if there's more specific information about the nature of the failure. See: 

• https://www.accesstomemory.org/docs/2.6/admin-manual/maintenance/logging/#web-server-logs
  

There's also Debug mode, which can sometimes catch errors that don't make it to the webserver, but is likely disabled by default on a production server: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/debug/
  

If it's data-specific, then running some of the common maintenance tasks can often help to resolve issues. I recently shared a summary of these in another thread - even though it was for a different issue, these tasks can often resolve common issues. See: 

• https://groups.google.com/g/ica-atom-users/c/Xt7kHtBuH3A/m/iY0od6W8AQAJ
  

Hopefully one of these suggestions will get you on the right track! 

Cheers, 

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

@accesstomemory

he / him

On Wed, Apr 13, 2022 at 10:23 AM York Explore Libraries and Archives <con...@exploreyork.org.uk> wrote:

Hello, we are using AtoM 2.6 but have a problem with unlinking physical storage. We are in the process of moving some archive boxes from one shelf to another, so we need to unlink the current container and relink to a new container. We are trying to do this from the archival description by clicking  on More/Link physical storage. However, when we try to delete the currently linked container the change cannot be saved and it remains linked to this container. Has anyone else had this problem? 

Thanks, Julie-Ann

--
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/b393611d-2c82-4dff-bb89-f38bebe95f75n%40googlegroups.com.

[Tim Schofield]

Hi Dan,

I've been working with Julie-Ann on this problem. She was demonstrating the problem - I looked in the Nginx error.log

and found this line at about the time she was demonstrating

2022/03/25 15:20:52 [error] 12301#12301: *1887446 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to a member function delete() on null in /usr/share/nginx/atom264EYLA/apps/qubit/modules/object/actions/editPhysicalObjectsAction.class.php:122

Another thing I did was run

php symfony physicalobject:normalize --dry-run

and go these results:

Data before clean-up:
 - 6109 physical objects
 - 85608 physical object relations
Detecting duplicates and updating relations to duplicates...
(Using physical object name, location, and type as the basis for duplicate detection.)
 - 395 relations updated
Deleting duplicates...
 - 113 duplicates deleted
Data after clean-up:
 - 5996 physical objects
 - 85608 physical object relations
Normalization completed successfully.

and ran

php symfony physicalobject:delete-unlinked --dry-run

and go these results

Data before clean-up:
 - 6109 physical objects

Detecting unlinked physical objects...
 - 862 physical objects marked for deletion

Deleting unlinked physical objects...
 - 862 physical objects deleted

Data after clean-up:
 - 5247 physical objects

Does this tell you anything new?

Regards

Tim

[Dan Gillean]

Hi Tim, 

According to one of our developers, who suggested the following: 

"The error is coming from an attempt to delete a physical object relation that points to a missing resource it looks like.  It does look like there is a mess in those physical object tables from the looks of the normalization attempt dry-runs.  I would take a db backup and then try running those normalization tasks to see if that clears things up."

Taking a backup first is important, because we're uncertain how the physical object management tasks will behave if there is data corruption. Without further information, we can't tell if the related physical objects are already deleted but the relations are not, or if there is some missing key relational data, such as an object ID for these physical storage containers.  

If running the physical storage management tasks does not work, I'd also suggest trying a few other maintenance tasks to see if they help, such as generating slugs, rebuilding the nested set, and reindexing. It's also often a good idea to clear the application cache and restart PHP-FPM before re-testing. These actions can often resolve common issues - see the Troubleshooting documentation page for links and more information on how to run each task:

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/
  

If that still doesn't work, then you have a few options. 

One thing you could try is attempting to determine if there is any remaining data corruption - we have a SQL query in the Troubleshooting docs that can help identify common forms of data corruption: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#dealing-with-data-corruption
  

However, this query is focused primarily on issues found in descriptions, so if the problem is in the physical objects, it may not help. 

In that case, you may need to write a SQL query to identify relations without physical objects, and delete them that way. 

Let us know how it goes!

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/5b634948-6290-4a98-bd19-d3613d0f7a2dn%40googlegroups.com.

[Tim Schofield]

Thanks, Dan, that's really helpful, I speak to Julie-Ann about it.