installation: public records, restricted fields?

[tiborsimko]

After basic access control is done, see basic I3B-Access issues, we should decide whether there is still a need to restrict some fields in an otherwise fully public record.

If not, good.

If yes, prepare an example for the Invenio 3 demo site, and amend integration tests.

[kaplun]

At INSPIRE legacy we were indeed hiding certain fields and making them available only to catalogers. I personally found this too complex of a requirement, so if it is too complex to implement I guess we can decide for a different technique (e.g. shadow records or similar).

[lnielsen]

I think this is fully the job of the serialiser. E.g. on Zenodo I have serialiser which only includes the files if a user actually have access to the files. So if we need it, then it's perhaps a "Restricted MARC21 serialiser" which is capable of remove specific tags. Note that indexing/searching should be taken into account as well.

[kaplun]

The only issue with a serializer is that once you start to get many of them you risk to forget to filter away fields from one of them. Maybe we could have a facility that can be hooked to filter fields before passing the record on to the serializers?

[aw-bib]

Indeed, there are fields in records that should not be visible in general, but are required e.g. for cataloguers. While we don't have it that much in bibliographic records, we more likely have it in authority data, a classic being email addresses in people authorities. How it's solved, I admit, I don't care to much, but I agree with @kaplun that it should be defined in some central place to avoid forgetting the filtering.

[lnielsen]

Generic utilities to filter JSON yes, and also great if your instance can centralise the filtering of records. However, you may have serialisers that need access to the restricted data in order to do a correct serialisation (without exposing the restricted data). That's why I suggest e.g. that we can implement Invenio 1/2 behaviour via a Restricted MARC21 serialiser.

You can compare it to rendering a template for a record - the template has access to the full record, but can take decisions based on current_user and permission checks whether something should be displayed or not.

On Zenodo I simply stick all the internal/restricted data in an _internal property in the record, and remove it when I do e.g. the indexing.