Unfortunately, at this time there's no built-in way to limit access to some authority record fields. In fact, we don't currently have a publication status (e.g. ability to set some authority records to Draft, so they are hidden from the public) for authorities either - something I hope very much we could add in the future.
For archival descriptions we do have the Visible elements module, which can be used to selectively hide some fields from public users - see:
However, this module too could use some enhancements. Currently, only the Physical storage data is also removed from CSV and XML exports and generated finding aids when hidden via Visible elements (and exports and finding aids are set to generate as public users). It would be great to be able to do further development so that any field hidden in Visible elements is also automatically removed from exports and finding aids.
As you may know, AtoM's development is driven by community support, either in the form of feature sponsorship or community code contributions. You can read more about the history of the project, and how we maintain and develop AtoM here:
If your institution has access to developers, we have a number of development resources
on our wiki to help you get started, and some recommendations when submitting major pull requests
back to the public project. If, on the other hand, your institution might be interested in sponsoring development to add support for Visible elements and/or a publication status for authority records, feel free to contact me off-list, and Artefactual can prepare some estimates for you. Some possible development tasks might include:
- Adding a publication status for authority records
- Adding authority record fields to the Visible elements module
- Enhancing the Visible elements module to also remove hidden fields from exports and finding aid generation
In the meantime: it wouldn't give you control over specific fields, but one thing you can consider for having more control over the visibility of other entities for public users would be to set up a separate read-only public site, with a replication script managing updates between your staff edit site and the public one. We offer this by default to our Premium+ hosting clients, and we have a bit more information on the setup and its advantages on our website, here:
Essentially, it's a public-facing read-only site and a secure internal read/write site for staff, with a replication script used to periodically copy the database, digital objects, and search index from the R/W site to the public one. This allows for not only greater security (since your internal site can sit behind a firewall, etc), but aggressive caching on the public site to help improve performance. Additionally, because you control the replication script, you can essentially choose when you push updates to the public site - meaning you can work on authority records internally, and they won't become publicly discoverable until you choose to run the replication script.
We've made the replication script that we use as part of this service publicly available for all to use, in our Artefactual Labs GitHub repository:
As I said, it's not exactly per-field visibility control (which would require development), but it might inspire some possible workarounds.