Populate the access.classification field

[perolavsvendsen]

This PR partly solves #295.

Metadata shall contain the access.classification field, the values shall be either internal or restricted. If the access_classification argument is given, it is used. First fallback is the global_variables/config. If not present in config, final fallback is default constant in fmu.dataio. This to ensure backwards compatibility, as this will hit several existing configs without this tag present combined with scripts without this argument given.

[perolavsvendsen]

Possible needed add-on: Synch with existing access.ssdl.access_level.

• We want to avoid inconsistencies. If ssdl.access_level is internal, access.classification should be internal. Similar with asset vs restricted.
• In transition phase, we may want to populate one with the other. E.g. if ssdl.access_level is given through arguments, and access.classification is not, we should use the value from ssdl.access_level to populate access.classification. Possibly.

[perolavsvendsen]

Possibly:

• Populate both ssdl.access_level and classification using the same input argument.
• Allow both access_ssdl and access_classification in a transition period, with same behaviour
• Attach deprecation warning to access_ssdl, nudge users onto access_classification

[jcrivenaes]

Would "paranoid" be in ALLOWED_ACCESS_CLASSIFICATION"....?

[perolavsvendsen]

We don't currently validate anything for the access_ssdl input argument I think. Valid values according to the schema is internal and asset.

[jcrivenaes]

This gets easily complicated. I think we need one more round on conceptual maturation, and e.g. see if we can re-use and extend the ssdl.access_level (as machine read, and not necessarily as ssdl context in reality) instead of introducing a new but rather similar classification and deprecate ssld.access_level?

[perolavsvendsen]

This gets easily complicated. I think we need one more round on conceptual maturation, and e.g. see if we can re-use and extend the ssdl.access_level (as machine read, and not necessarily as ssdl context in reality) instead of introducing a new but rather similar classification and deprecate ssld.access_level?

The problem with continuing with ssdl.access_level is that it semantically links to SSDL. So it may be confusing to communicate that this argument shall be used even for things not related to SSDL. At some point, OSDU will also hit making this possibly even more counter-intuitive.

Another issue with the current argument is that it is bundled with rep_include which has some connection to ssdl.access_level but not to information classification in general. Furthermore, this argument uses the arbitrary "asset" value for something that is probably similar to "restricted". Machine-wise it is fine, but it may be complicated to communicate.

So the "proper" way is probably to:

• Detach rep_include into a standalone argument
• Introduce classification as a standalone argument
• Deprecate (over time) access_ssdl

The challenge is the transition period, when everything must be backwards compatible and preferably work simultaneously, while not having any inconsistencies.

If this was a purely "under the hood" thing, I wouldn't mind, but this is both exposed in the data model (which must be documented and understood, also outside FMU context) and in the API to fmu.dataio.

I will give it one more go to see if it is possible to achieve something sensible that allows for an introduction of more proper arguments, but yes, possibly it needs to mature. In that case, we must populate access.classification from ssdl.access_level.

[perolavsvendsen]

See attempt of light implementation in #324 @jcrivenaes

[perolavsvendsen]

This should also be closed given ongoing work on Pydantic etc, but discussion is relevant ref chat about the current logic around access. Current state is a light implementation/small step version of this larger stale PR. @janbjorge