Can't set a data object private by the share button

[taojing2002]

Describe the bug
I tried to use the Share button in the metadata editor to make a data object private in a package. However, the data object is public readable after the package was created.

To Reproduce
Steps to reproduce the behavior:

1. On the metadata editor page
2. Click on the "Share" button associated with the data object
3. A pop up window shows the access options
4. Toggle the private button (The attached screenshot shows the screen before I clicked the save button.)
5. Click the Save button on the access options page
6. Click the Save button on the metadata editor page

Expected behavior
The data object should be private. However, the metadata shows it is public readable.

Desktop (please complete the following information):

• OS: Mac OS
• Browser: Chrome
• Version: MetacatUI 2.18.0
  

[taojing2002]

It turns out the knb theme works but the default theme doesn't.

[amoeba]

I can't reproduce on develop with either the default or arctic themes so far. I'm going to coordinate with @taojing2002 via Slack to try to find a reproduction.

[robyngit]

Thanks @amoeba!

[amoeba]

I was able to reproduce it and can partly explain why this works on the knb theme and not the default. Here's a more specific set of steps to reproduce:

(Using the default theme, tip of develop)

1. Navigate to the editor
2. Attach a file
3. Open the Share dialog for the file
4. Click Save in the Share dialog
5. Look at the Network pane and notice the sysmeta still contains public-read when the editor fetches the sysmeta after the updateSysMeta call

Why this works on the knb theme and not the default theme has to do with whatever the actual bug here is: If, when you toggle the file from public to private, the public-read rule was the last rule in the AccessPolicy, the rule appears to get removed from the AccessPolicy collection but the change isn't reflected when the sysmeta is updated. When the public-read rule is not the last rule (as is the case for the KNB because we always add the knb-data-admins group), the sysmeta does get updated.

The fix is probably a small change but I don't have time to figure it out at the moment. @robyngit can I kick this back over to you to look into in the future?

[robyngit]

Thanks for the summary and for figuring out how to reproduce it, @amoeba! I'll look into it further.

[robyngit]

This behaviour stemmed from a problem in the serialization of the system metadata. The old <accessPolicy> node was not being updated or removed when the new access policy was empty.