dataoneorg / d1_cn_rest Goto Github PK

We found an issue that cn.archive can't handle the pid http://dx.doi.org/10.5061/dryad.12?ver=2017-08-29T11:52:08.075-04:00 correctly.
First we thought there was an issue in Metacat. After some poking around, it seems the issue is not in Metacat. The details is in this [ticket].(NCEAS/metacat#1711)

Problem

Currently, our CNIdentity.updateGroup endpoint requires the client to send the complete Group object when they want to add new members to a group. This means the client must know all the existing members of the group, which may not be feasible or efficient in all scenarios. It also adds extra complexity and potential for errors, as the client has to manage the state of the whole group.

Expected behaviour

I would expect changes to a group should be possible with minimal input from the client.

I propose adding a new endpoint which would allow clients to add new members to a group by sending only the new members' details. This way, the server would handle merging the new members with the existing ones, thus reducing client-side complexity and potential errors.

Context

The current implementation recently caused an issue within MetacatUI. @vchendrix reported a problem where a user was added a large group of 263 member before the group was fully loaded in the UI. It lead to the group losing about a third of its existing users due to an incomplete group being sent to updateGroup.

We have considered client-side mitigations like delaying user actions until the entire group is loaded, though in this case, it takes ~30 seconds for the API to return a response (https://cn.dataone.org/cn/v2/accounts/CN%3Dess-dive-users%2CDC%3Ddataone%2CDC%3Dorg).

In the capacity of a member node, it shows two subjects in the service restriction part:

<service name="MNStorage" version="v1" available="true">
  <restriction methodName="create">
    <subject>http://orcid.org/0000-0002-1209-5268</subject>
    <subject>cn=parc,o=PARC,dc=ecoinformatics,dc=org</subject>
  </restriction>
  <restriction methodName="update">
    <subject>http://orcid.org/0000-0002-1209-5268</subject>
    <subject>cn=parc,o=PARC,dc=ecoinformatics,dc=org</subject>
  </restriction>
</service>
<service name="MNStorage" version="v2" available="true">
  <restriction methodName="create">
    <subject>http://orcid.org/0000-0002-1209-5268</subject>
    <subject>cn=parc,o=PARC,dc=ecoinformatics,dc=org</subject>
  </restriction>
  <restriction methodName="update">
    <subject>http://orcid.org/0000-0002-1209-5268</subject>
    <subject>cn=parc,o=PARC,dc=ecoinformatics,dc=org</subject>
  </restriction>
</service>

However, it only shows one subject on the cn part after a user updated the node capactiy:

<service name="MNStorage" version="v1" available="true">
  <restriction methodName="create">
    <subject>CN=parc,O=PARC,DC=ecoinformatics,DC=org</subject>
  </restriction>
  <restriction methodName="update">
    <subject>CN=parc,O=PARC,DC=ecoinformatics,DC=org</subject>
  </restriction>
  </service>
  <service name="MNStorage" version="v2" available="true">
  <restriction methodName="create">
    <subject>CN=parc,O=PARC,DC=ecoinformatics,DC=org</subject>
  </restriction>
  <restriction methodName="update">
    <subject>CN=parc,O=PARC,DC=ecoinformatics,DC=org</subject>
  </restriction>
</service>

You can see the ORCID http://orcid.org/0000-0002-1209-5268 is missing.
I looked at the LDAP server on the CN which stores the node information and found there is no information for the ORCID. So somehow, the first subject was skipped during the registration/update process.