Access to Memory (AtoM)

First reported in the User Forum: https://groups.google.com/d/msg/ica-atom-users/XWyADd9kXsE/SKQW3H3hAQAJ

This was tested and reproduced in the ISAD template. Its impact on other templates should be considered as well.

• Import a CSV. It should only a single row for the creator and date - not piped w NULL as happens on export. I've attached a sample.
• Navigate to the imported record
• Enter edit mode
• Delete the link to the creator. Note that the dates are in a different Information area, and technically should not be affected by this.
• Save and view the record

Resulting error
When records are imported this way, removing the creator deletes the entire database row, thereby also deleting the date.

Expected result
Dates should not be deleted if just the creator is removed in the ISAD template.

Comments from the reporter

Scenario 1: An archival description has a Creator and Creation Date assigned during a CSV import (both elements being set in the same record)

When I edit an archival description, delete the Creator from the Context area, and then save the record, AtoM also deletes the Creation Date from the Identity area of the record.

Scenario 2: An archival description has a Creator and Creation Date assigned via the web interface

When I edit the description, delete the Creator, and then save the record, AtoM leaves the Creation Date on the record.

I would think that in both cases AtoM should leave the Creation Date on the record. Looking at the database, it seems that Scenario 2 creates two separate rows in the event table, while Scenario 1 creates a single row. Deleting a Creator seems to delete the row in which the Creator Actor appears, but perhaps it should just set the actor_id to NULL and keep the row?

Just to clarify here, I mean to say that since deleting a Creator seems to delete the row in which the Creator Actor appears, in Scenario 1 the actor_id should be set to NULL without deleting the row, while in Scenario 2 it makes sense to delete the row, since the Creation Date is stored in a separate row.

Notes

I'm filing this ticket so we can consider the request, because the current behavior is counter-intuitive. Given how we've had to make things work for both ISAD and RAD via a compromise, I wonder how the UI will know the difference of situation? It's worth considering however - this is buggy behavior.

Note that the workaround would be to import using | pipe separators and NULL values to separate the creator from the date in the database.