[Archivesspace_Users_Group] Odd data modifications during aspace updates.

[Donald Mennerich]

 Hello,

While testing a script that was updating a resource's ead_id via the api I
noticed that the timestamps for  most sub-records of the resource, e.g.
instances, extents, langmaterials, etc., that wern't part of the update
were havign their timesstamps, includeing create_time and created_by,
updated as well. I naturally assumed there was something wrong with my
code, but when we tested updating a resource record from the staff
interface the same thing happening was observed.

For example, the fields belonging to the Resource model updated as
expected, the creation_time and created_by were not modified, while the
last_modified_by and mtimes were:

*Before*

> {  "lock_version": 1,  "title": "Test Collection",  "publish": true,  "restrictions": false,  "created_by": "admin",
>
>   "last_modified_by": "user1",  "create_time": "2016-07-14T23:50:37Z",  "system_mtime": "2018-03-29T22:05:59Z",  "user_mtime": "2017-02-02T18:15:58Z",
>
>  ...
>

*After*

> {
>   "lock_version": 2,  "title": "Test Collection",  "publish": true,  "restrictions": false,
>
>   "ead_id": "test_999",  "created_by": "admin",
>
>   "last_modified_by": "user2",  "create_time": "2016-07-14T23:50:37Z",  "system_mtime": "2020-03-10T17:29:46Z",  "user_mtime": "2020-03-10T17:29:46Z",
> ...
>
>

But in most of the subrecords of the resource the timestamps have all
updated to the time of the update of the resource record. In this case the
only thing that was updated was in the resource record was the eadid, but
the instance subrecords had their timestamps updated even though not at all
part of the update. Note that while data was changed in the sub record the
lock_version is still at 0. Again, this was done with an update via the
staff interface.

*Before*

> "instances": [
>   {
>     "lock_version": 0,
>     "created_by": "user1",
>     "last_modified_by": "user1",
>     "create_time": "2017-02-02T18:15:58Z",
>     "system_mtime": "2017-02-02T18:15:58Z",
>     "user_mtime": "2017-02-02T18:15:58Z",
>     "instance_type": "mixed_materials",
>     "jsonmodel_type": "instance",
>     "is_representative": false,
>     "sub_container": {
>       "lock_version": 0,
>       "created_by": "user1",
>       "last_modified_by": "user1",
>       "create_time": "2017-02-02T18:15:58Z",
>       "system_mtime": "2017-02-02T18:15:58Z",
>       "user_mtime": "2017-02-02T18:15:58Z",
>       "jsonmodel_type": "sub_container",
>

*After*

> "instances": [
>   {
>     "lock_version": 0,
>     "created_by": "user2",
>     "last_modified_by": "user2",
>     "create_time": "2020-03-10T17:29:47Z",
>     "system_mtime": "2020-03-10T17:29:47Z",
>     "user_mtime": "2020-03-10T17:29:47Z",
>     "instance_type": "mixed_materials",
>     "jsonmodel_type": "instance",
>     "is_representative": false,
>     "sub_container": {
>       "lock_version": 0,
>       "created_by": "user2",
>       "last_modified_by": "user2",,
>       "create_time": "2020-03-10T17:29:47Z",
>       "system_mtime": "2020-03-10T17:29:47Z",
>       "user_mtime": "2020-03-10T17:29:47Z",
>       "jsonmodel_type": "sub_container",
>


I'm trying to determine if this is a local problem or if this is just
normally how aspace manages updates, and if so is it a bug. Would someone
with access to the API of their ArchivesSpace instance see if they could
reproduce this? I've tested this on installations of v2.7.0 and v2.7.1.

Thanks,

Don
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200310/7a371db6/attachment.html>