Metadata Security Settings on a Person's Email do not work when `metadata.hide.person.email = true`

[tdonohue]

Describe the bug

This issue was found during testing of #5145, the PR which adds these new metadata security settings.

While the settings work for Person's "Birth Date", they do NOT work for a Person's "Email"

The reason appears to be because we hide the email field (by default) in our dspace.cfg (for security reasons):

metadata.hide.person.email = true

To Reproduce

Steps to reproduce the behavior:

1. Ensure you have the default settings of metadata.hide.person.email = true specified
2. Edit a Person entity (using the new Edit Form)
3. Add an Email Address and a Birth Date. Change the security option to "public" (globe icon) for both
4. Save the changes
5. Logout to become anonymous
6. Visit the Person page. Notice that, even though they have the same security settings, the Birth Date is visible, but the Email is NOT visible

Expected behavior

The current behavior is correct because metadata.hide.* configs should always override any metadata field specific security.

However, the user interface behavior is confusing to users because it appears they should be able to manage the security settings of this person.email metadata field.

To fix that, it seems like we have two main options:

1. Either we remove the security options from the Email field by default, i.e. update the metadata-security.cfg to remove this setting

   metadatavalue.visibility.Person.person.email.settings = [0 1]
   

2. Or, we do not display the security toggle whenever metadata.hide.* is enabled for a given metadata field. This might be done on the backend if we ensure metadata.hide.* settings cause similar settings in metadata-security.cfg to be ignored.
   • For example, if metadata.hide.person.email = true is set, then that forces metadatavalue.visibility.Person.person.email.settings = [ ] (even if some different value for that setting appears in metadata-security.cfg.

I have a slight preference for the second option because it ensures any misconfiguration is automatically ignored. But, either approach could work.

Related work

This "Metadata Security Settings" feature was introduced in #5145.