Wrong access policy created with clone_package()

[laurenwalker]

After creating #220 and playing around more, I noticed some weirdness.

I'm currently cloning packages from the Dangermond repo to dev.nceas (eventually they will be on the KNB but I wanted to test first). I also want to add the KNB Data Admins group to the permissions of each package. Here are my results:

I executed in R...

clone_package(rMapPid, from, to, add_access_to="CN=knb-data-admins,DC=dataone,DC=org", change_auth_node=TRUE, public=TRUE, clone_children=TRUE)

The original resource map access policy

<rightsHolder>http://orcid.org/0000-0002-1678-0975</rightsHolder>
  <accessPolicy>
    <allow>
      <subject>CN=dangermondpreserve-data-admins,DC=dataone,DC=org</subject>
      <permission>read</permission>
      <permission>write</permission>
      <permission>changePermission</permission>
    </allow>
    <allow>
       <subject>public</subject>
      <permission>read</permission>
    </allow>
</accessPolicy>

The cloned resource map access policy - has bugs

<rightsHolder>http://orcid.org/0000-0003-2192-431X</rightsHolder> <!-- Lauren -->
<accessPolicy>
     <allow>
         <subject>CN=arctic-data-admins,DC=dataone,DC=org</subject> <!-- Not in the original access policy -->
         <permission>read</permission>
         <permission>write</permission>
        <permission>changePermission</permission>
      </allow>
     <allow>
         <subject>public</subject>
         <permission>read</permission>
      </allow>
      <allow>
         <subject>CN=knb-data-admins,DC=dataone,DC=org</subject>
         <permission>read</permission>
         <permission>write</permission>
         <permission>changePermission</permission>
      </allow>
</accessPolicy>

The original EML access policy

<rightsHolder>http://orcid.org/0000-0002-1678-0975</rightsHolder>
<accessPolicy>
      <allow>
        <subject>public</subject>
        <permission>read</permission>
      </allow>
      <allow>
        <subject>CN=dangermondpreserve-data-admins,DC=dataone,DC=org</subject>
        <permission>read</permission>
        <permission>write</permission>
        <permission>changePermission</permission>
      </allow>
</accessPolicy>

The cloned EML access policy - no bugs!

<rightsHolder>http://orcid.org/0000-0002-1678-0975</rightsHolder>
<accessPolicy>
        <allow>
            <subject>public</subject>
            <permission>read</permission>
        </allow>
        <allow>
            <subject>CN=dangermondpreserve-data-admins,DC=dataone,DC=org</subject>
            <permission>read</permission>
            <permission>write</permission>
            <permission>changePermission</permission>
        </allow>
        <allow>
            <subject>CN=knb-data-admins,DC=dataone,DC=org</subject>
            <permission>read</permission>
            <permission>write</permission>
            <permission>changePermission</permission>
        </allow>
</accessPolicy>

Unexpected behavior

• I did not expect the arctic-data-admins group to be added the access policy of the resource map when I did not state that in my add_access_to parameter and it was not in the original rmap access policy. It must be hard-coded in datamgmt somewhere?
• I did not expect the dangermondpreserve group to be removed from the rmap access policy
• I did not expect the original rightsHolder of the rmap to change to me

Expected behavior

• The cloned EML access policy is exactly what I expected. The add_access_to group is added, the original rightsHolder is intact, and there isn't the extraneous arctic-data-admins group
• The resource map and EML access policies should match

---

This bug ties into the UI where the Editor only shows the access policy of the EML. So one might look at it in the UI and assume everything looks great. And when I Save the access policy in the Editor, I can never get the resource map and EML in sync. I think this actually inadvertently helped me reproduce this (NCEAS/metacatui#1916) MetacatUI issue that I've been struggling to debug.

---

To reproduce

Run this script:

# Copy a data package to another member node!

library(datamgmt)
library(dataone)

rMapPid="urn:uuid:3c52e2ee-a794-4b69-83e0-1e3c7ace477c"
from_d1Env="PROD"
from_d1Node=MNode("https://dangermond.dataone.org/metacat/d1/mn/v2")
to_d1Env="STAGING"
to_d1Node=MNode("https://dev.nceas.ucsb.edu/knb/d1/mn/v2")
options(dataone_test_token = "...")
adminSubject="CN=knb-data-admins,DC=dataone,DC=org"

# Create the DataONE Nodes
from_cn=CNode(from_d1Env)
to_cn=CNode(to_d1Env)
from=D1Client(from_cn, from_d1Node)
to=D1Client(to_cn, to_d1Node)

# Clone the package
clone_package(rMapPid, from, to, add_access_to=adminSubject, change_auth_node=TRUE, public=TRUE, clone_children=TRUE)

[jeanetteclark]

I looked into this and it's because clone_package creates a new resource map after copying all the objects using arcticdatautils::create_resource_map. By default all the arcticdatautils publish functions add access to the ADC admins group, as shown above. In contrast to the resource map, all the data objects are published using dataone::createObject so there aren't any automatic modifications.

I think the solution here is just to remove that arcticdatautils dependency and create the resource map another way. We could just clone the resource map like any other object, but that definitely won't work if we are changing pids, and I wonder if there are other node specific things in the resource map, or if all the URLs are written with dataone endpoints (I think they should be? not 100% sure)

[mbjones]

As an aside, datamgmt should not depend on arcticdatautils -- rather the dependency should be the other way, and we should npt have circular dependencies.

[jeanetteclark]

Yup agreed. Stripping datamgmt back to just the clone/copy functions, and rewriting them so they are more robust and don't depend on arcticdatautils I think would be a good direction for this package

[mbjones]

Glad to hear that. Also, in general I think it is error-prone to create a resource map from scratch rather than modifying the existing one by adding and deleting triples. I think from-scratch recreation of the map has a high probablility of creating bugs, and has been my primary complaint about arcticdatautils over the years. Resource Maps are designed to support extension, and so client tools need to preserve all of the contents of the RM, including statements the client itself doesn't understand, or new types of information that are added in the future.

[laurenwalker]

I wonder if there are other node specific things in the resource map, or if all the URLs are written with dataone endpoints (I think they should be? not 100% sure)

I just checked and there are no other node-specific things written to the resource map itself. It does use the production CN URL rather than the cn-stage URL, which is the environment I was writing to. But that's not a big deal.